Allow to provide own locations for zlib, openssl etc #2474
Conversation
Allow to provide own locations for zlib, openssl, libssh2, cares. The link.exe /lib failed, because it added (Microsoft) dependencies. As create a static lib is just aggregating objects into an archive, use lib.exe instead. As lib.exe does not perform optimizations nor linking, the optimizations and dependent windows libraries should not be provided as flags to the archiver.
|
Ref: #1201 @kdekker the variables you're adding need to be documented @rodwiddowson can you give feedback on this pr please |
|
First of all: the current approach differs from #1201. In the #1201, I added variables that manipulate CFLAGS en LFLAGS directly. In this approach, I provide e.g. ZLIB_PATH that points to a location where a include and lib subdirectory are expected. A somewhat (but that is my opinion) cleaner approach compared to previous one (but judging own changes is not an independent opinion..) In addition to the comments mentioned in #1201, I cannot use nmake /E. That option only allowed to set environment variables, but these then need to be used/available in the makefile. Prior to my PR, the MakefileBuild.vc only provided the WITH_DEVEL possibility. That variable lacks the possibility to take zlib, openssl, libssh2 (and what you need more) from different locations. WITH_DEVEL also requires first to copy all other includes/libs on a per user, per version basis. It is also against the common practice on UNIX/Linux, where you can provide a path to another lib/include. As an example: if you write some C-code, using a #include directive, then the include file should be found by providing the right /I flags. Considering this way of working, the way how WITH_DEVEL works (copying instead of referencing a location) is IMO odd or special (or probably normal, based on what someone considered as 'normal', and depending on what your opinion is). When we started using cURL (many years ago), the old nmake method also provided a possibility to define 'your own' locations for zlib, openssl etc. In our case, these libraries are stored in a read-only location. It is inefficient to rewrite our build process and need to copy (for each build, for each user) the other includes/libraries used together with cURL. Inefficient in terms of writing a different process, inefficient in terms of inflexibility if we need to test cURL with e.g. different openSSL versions. I hope that I've convinced you for the need of the possibility to specify other locations. Please keep in mind that I did not change the default (../../deps directory). Some additional information about my changes (the line numbers refer to the code as if my PR was applied):
I hope that the above information clarifies the background of my changes. A few of them (the last bullet of previous comment) should probably get its own PR. I will try to do so next time... With the original sources, building in it simpelst from results into warnings, that point to wrong commands. In my example below, I just extract the curl 7.59 sources, open a VS2016 x64 native command prompt and run: nmake /f Makefile.vc mode=static DEBUG=no That command will result in the following warnings, which are solved after my PR will be applied (due to the switch to lib.exe instead of link.exe and not passing Windows libraries to the build command): wldap32.lib(WLDAP32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in ws2_32.lib(WS2_32.dll); second definition ignored The above warnings mean that the same symbol (from Windows system libraries) are added twice. @jay: I add documentation, but first like to await a response on this comments. I think I've to write some words in BUILD.WINDOW.txt and in the usage in the MakefileBuiild.vc. Is that sufficient for documentation? |
|
@jay: |
|
Please add the documentation in Makefile.vc and BUILD.WINDOWS. Add it at the end of section |
|
I will do so, and send an additional commit on my own repository (that will become visible automatically here if I understood the process) in a while (as soon as I've finished the change). Removal of the release-ssh2-ssl-dll-zlib section was indeed not needed. I just saw commented out lines that did not match (IMO) with the remainder of the structure of the makefile. I did not see the benefits, and probably removed it too quickly. This is common practice in our own version control system, where 'code that is not used' is usually removed. Code that is not used, increases complexity and makes understanding more difficult (that's is also why I asked in another mail about dropping visual studio 6). Any code that exists, has a price. You will get nothing for free...But if you like that I leave this commented out lines, I will re-add them. However, some few words why these lines should exist, is probably a good idea. |
Some new variables have been introduced to tell locations of dependencies, e.g. for OpenSSL. Also removed a dangling URL that no longer worked. I was not able to find the IDN download at MSDN/microsoft.com, so it seems to be removed...
|
Filed a new commit that added the requested documentation. Will this commit (d4382e9) automatically become part of this PR? (I'm still not knowing enough of git to know this). Also removed an URL (for IDN libs) that seems no longer to exist at MSDN/microsoft.com. |
Yes since you pushed it to the branch associated with this PR it is seen in the PR. Ideally something like this you'd squash it or amend it to the previous commit and then force push. What happens if any of the _PATH options are used with WITH_DEVEL? can we just make them one liners like |
|
If one of the _PATH variants is used WITH_DEVEL, only the xxx_PATH is used for product xxx and the remainder will use the default, of course respecting the value provided with WITH_DEVEL. In terms of code: combined with zlib as example will probably better explain my answer. As you can see, the one is set, and the xxx_PATH overrides, but only when provided. I don't understand how this can be reduced to one liners? We need both a path to include as well as to a library. And these need to be used in compiler and/or linker flags if a dedicate _PATH value was provided. If all includes and libs are in the WITH_DEVEL location (don't make difference if this value has its default value, or got a user specified value), then next trick is used to provide a single include and linker path (and thus, these need not to be speficied again in the else branch of the above piece of code): |
|
Ok. I meant reduce the documentation for each variable to a one liner like in my example. |
|
Ah, I did not understand that. But keep in mind that the _PATH variables were only added for 4 libraries. Not for all stuff (like WITH_NGHTTP2 and some others). When reducing the documentation to one line, it is still useful which libraries has a _PATH variable, isn't it? |
|
@jay: Do I need to provide more information? Is the explanation clear, or do I need to change more things. I would really like to know whether this PR will be merged or whether I need to do something more. |
|
I think we should support this for nghttp2 and mbedtls as well that way all the WITH_ options have a _PATH. For the doc what do you think about this: |
|
Perfect. Shall I make that change and make a commit in my own repo (for BUILD.WINDOWS.txt + usage information in makefile)? If wanted, I can make the nghttp2 and mbedtls changes as well (in the makefile + documentation), but I'm not known with these. So testing becomes difficult for me. Who can test my changes then? I already discovered that there is some inconsistency between e.g. USE_SSL and USE_NGHTTP2. In the first case, USE_SSL remains undef if not set, while USE_NGHTTP2 becomes 'false' (in Makefile.vc) + no /I directive is ever used for NGHTTP2. So additional testing is really needed, but actually out of my scope. |
As requested by Jay Satiro: added similar possibility for remaining 2 left-overs (NGHTTP/2 and mbedTLS) similar to was done before for zlib, openssl, libssb2, cares. Also applied proposed change to the documentation (including the 2 new xxx_PATH possibilities).
|
Made a commit. Makefile checked on syntax correctness, but did not build with NGHTTP/2 and/or mbedTLS. |
There was a problem hiding this comment.
Data point. This file breaks my curl build as it currently stands,
I'm investigating.
I cannot use the new features since I also need control over the lib names which this change doesn't offer.
I'd appreciate it if we didn't get this into mainline until I u nderstand fully and either decide my build it bhroken or we can work out what will work.
My Breaking command line:
Nmake /f Makefile.vc mode=dll WITH_DEVEL=H:\Perforce\VS2017\openssl-1.1.0g\x86
WITH_SSL=dll WITH_ZLIB=dll ENABLE_WINSSL=no VC=15 MAKE="NMAKE e"
ZLIB_LFLAGS=/libpath:H:\Perforce\VS2017\zlib-1.2.11.\Release ZLIB_CFLAGS="/D
HAVE_ZLIB_H /DHAVE_ZLIB /DHAVE_LIBZ /IH:\Perforce\VS2017\zlib-1.2.11"
ZLIB_LIBS=zlib1.lib SSL_LIBS="libcrypto.lib libssl.lib" BASE_NAME=libcurl7_58
BASE_NAME_DEBUG=libcurl7_58d
|
@rodwiddowson: please show your directory structure and involved library names. There are a few IF EXISTS() constructs, e.g. to determine the naming of OpenSSL, but these existed before. I added a similar construct for zlib. Do you use your own lib names, or are the used lib names default? Why is the check for e.g. openSSL not smart enough for you? Library names do not change that often (hopefully)? Based on your build flags: the names of the openSSL libraries should be recognized, but will fail if you store multiple versions of OpenSSL in the WITH_DEVEL directory. Instead of it, use dedicate output directories for OpenSSL, and use SSL_PATH. For the output result of cURL (you are using non-default names for BASE_NAME and BASE_NAME_DEBUG), I don't see a relationship with my changes... So: for which library names do you need control for? Anything else than cURL is IMO 'dicatated' by the 'other-product' maintainers. And the cURL output itself can be controlled, as it could before. Or am I wrong? |
|
OK. My PEBKAC confirmed. I'm fine with this change. Sorry for the noise. I may need to do some cleanup of our build processes to take full advantage of this (probably by adding an install target to our zlib build), but thats my problem, not libCurl. Once again sorry about the noise. |
|
LOL. Learning a new word (PEBKAC) 👍 (English is not my native language) |
|
Thanks |
|
Thanks Jay (and all others that were involved). |
I'm guessing this part broke pycurl build which links statically against libcurl and all of libcurl's dependencies. And if I am understanding this PR correctly, in order to bulid pycurl now it needs to know all of the library dependencies that libcurl has (like what c-ares's library is called), which is not at all ideal. |
I suggest a less guessing and more fact-based approach.
If you wanted to build with a static libcurl you always needed that. This PR just made it possible for you to point to different install paths for a few different dependencies, which wasn't previously possible. |
This is not the case as 1) mentioned in the original description of this PR and 2) can be seen from https://github.com/pycurl/pycurl/blob/cad5d37b2365d5158839acf27f25bb40bbd17d06/winbuild.py. My impression of how libraries (*.lib) on windows work is they can embed, in particular, references to other libraries which will be used during linking stage later. libcurl used (up until 7.59.0) to embed references to its dependencies like libcares.lib, and in 7.60.0 does not resulting in missing symbols at link time unless all of these libraries are manually specified during the build process of the program using libcurl. |
|
Yes, thanks a lot @kdekker for the added explanation (I had missed that point). |
Windows doesn't have pkg-config that takes care of this on Unix-like platforms.
Well, yes. Most/all Unix-based projects that support building under MSVC have some kind of a homebuilt windows build system. Pycurl's one is up to 1100 lines, libcurl has one and all of libcurl's dependencies have their own. Are you saying that because libraries are not embedded on Unix they should not be embedded on Windows? If this was the sole motivation for the change in this PR I'm afraid it's not a very good one. I looked through the comments here and in #1201 again and I don't understand what actual problem the link->lib change in this PR was solving. Warnings about duplicated libraries from MSVC? Are you building statically or dynamically? If statically, are you building all of the dependencies yourself so that they have the same exact build settings? To me this PR is a significant usability regression for building software against libcurl on windows statically. It probably doesn't matter in dynamic builds. But I worked around this already and I am happy to wait for other affected parties to chime in, it is possible that I imagined all of the issues that this change caused in pycurl. |
|
@p: I agree with you that 'making Windows as much as UNIX/Linux' behaves is not an end in itself, but it may help if it is more similar (for multi-platform developers). I'm using static libs for all. The actual problem with link /lib is:
Although link /lib may work better for linking DLL lib (stubs), it does not work for static libs. In our case, zlib, curl, ssh2 and openssl (and much of our own libs) are static libs (built by ourselves). Adding references to DLL lib (stubs) is a good idea, but does not work (see details above of a post of 10th April, where the the build errors I got have been posted). That's why I said: Either use the list of (configuration dependent) Windows DLL libs from MakefileBuild.vc or use #pragma lib in your own source code. Rolling back my changes results in build errors for me. BTW: the primary goal of this PR was:
|
|
If you can repost those errors that would probably help understand the situation. |
|
@p: I don't have the output of the original error anymore. But the error is already in this thread (see April 10 post). |
|
I see a bunch of warnings in that post, where is the error? It also occurred to me that if you are building statically against libcurl, unless you have https://github.com/pycurl/pycurl/blob/1258db7ccca677f48a0ab053a9fbce0a144000fb/winbuild/libcurl-fix-zlib-references.patch applied all of libcurl's dependencies specify /MD and libcurl specifies /MT, at which point you'd probably have two different CRTs referenced which will surely fail the build. The correct fix here is the patch linked though because otherwise you're building with the wrong flags. |
|
I'm getting in doubt. Maybe it were only warnings. But anyhow: severe warnings. I need to spend more time (which I don't have now) to checkout what errors happened. From what I remember, next steps were performed (all static libs):
If I remember well, it is impossible to to include both openssl and curl libs when building a own binary. But why should you prefer an obsolete/undocumented link /lib command? Such commands have a risk, and MS may remove support for it in a future version. IMO: using undocumented features is not the wat to go... (in any case) And no, I'm not using the wrong runtime or mixing runtime flags. All is dynamic DLL. Based on curl 7.59.0. This is libcurl, not pycurl IMO. What is the relationship with that change? In general, using static RTL libs is a bad idea though (for a lot of other reasons). |
This is simply not an accurate statement.
It does not matter to me how libcurl.a gets all of its dependencies aggregated into it, just that it does. Perhaps this can be accomplished with lib.exe, which would be fine. On the other hand MS goes to extreme lengths to maintain compatibility and the existing usage of link.exe, even if presently undocumented, is probably well established and unlikely to disappear.
Unless you patched libcurl not to request /MT in static builds that's what you will have going on. The patch referenced is a libcurl patch, please do look at it more carefully and do not let the name mislead you (it's there for historical reasons only). |
Why not? Please argue... Please understand that I don't have all details available on something that has changed almost 2 months ago. You can also do your own research and test work, based on what I have written down, isn't it?
Is that not short-sighted? If someone likes to know more about how MakefileBuild.vc has been setup, it is clear that finding references/documentation is not optional, but a must-have, isn't it?
I did not say anywhere that I did use static RTL libs (instead, I have said the opposite: I'm using dynamic RTL libs!). I don't see the effect of this patch if dynamic runtime libs are being used. But instead of asking me to prove things, why do you not comment on any of the proposals I did? It is quite normal IMO to specify required Windows runtime DLL lib stubs when building your own binary or DLL. Just grab out WIN_LIBS value from MakefileBuild.vc, and you are fine when adding this value to your link command. What's wrong in doing so? And until now, I'm not aware of other complaining guys (my fix has been incorporated into curl 7.60.0). You even did not tell which curl version is being used by you... (I assume it is 7.60.0). |
pycurl has been built this way since 2015. Yesterday I built a libcurl_a.lib which incorporates cares+nghttp2+openssl+etc. static libs into it for libcurl 7.59.0 and it worked fine.
I do not understand your question. Is it shortsighted to use an incantation that probably originated 15+ years ago and hasn't been changed in at least this much, and works fine? Is it shortsighted to replace that incantation with a different incantation which is documented but doesn't perform the same function?
I assume in your program you do but so far the responses you are giving indicate that you are using libcurl's default configuration which references static MSVCRT in a static build.
I only came across this PR after libcurl 7.60.0 broke pycurl's build process on windows.
This is called "abstraction leakage" or encapsulation violation. pycurl shouldn't need to know that libcurl is built against c-ares, libssh2, etc. pycurl's code is the same whether libcurl is built against those optional dependencies or is not. The only thing pycurl SHOULD need to specify is which libcurl to use.
Yes. See here:
|
This has been possible going back to at least libcurl 7.19.0 by specifying INCLUDE and LIB environment variables appropriately. See https://github.com/pycurl/pycurl/blob/c5ebff86aa7dfd67da62e2e4b94c3ef9d8b7e1c4/winbuild.py#L799 onward, this code works from 7.19.0 through 7.60.0. The
So the only way to use these Now, you might be asking, what's the harm in having extra configuration options? The problem is they suggest themselves as the options to be used to, for example, specify where zlib is, and as we have established they don't work for default configurations of libcurl's dependencies nor are they particularly flexible. An unsuspecting user is very likely to spend a significant amount of time trying to figure out why nothing happens when they use Hence my recommendation would be:
|
We are using curl as of 2008. It worked fine when we were using nmake files (Makefile.vc). These files have been dropped by curl, and I had to move to something else. The Makefile[Build].vc approach was suggested as alternative. It was tightly bound around a single 'devel' directory, which was too inflexible for me. So I had to change things to get it working (and others provided feedback about the changed method). You are the first one (AFAIK) that is complaining about the different way of (not) incorporating system DLL/library dependencies.
The 'it has worked before' argument is probably valid (but may block any modernization, if needed), but 'you have to use supported and documented tools and options' is also feasible. At this time I don't know whether the lib.exe is not capable in adding the runtime dependencies. May be it is. You can check. I will try to check if I've time next week...
Hmm... really? I'm not sure to call this abstraction leakage, because the way how you build curl is up to you. So anyone can choose to build curl with/without a lot of options (ares, http2, openssl). It is obvious that using different options change the dependencies to system DLLs. So, I can't really imagine that the person who uses (or even built libcurl on his own) don't know what system DLL libs to add as dependency. You can add all Windows system libs in your build command. Visual Studio automatically omits any DLL not used. BTW. this is the common way how Visual Studio project/solution files have been setup. It always links e.g. user32.lib, gdi32.lib etc. It does not harm to add too much libs here. You only (once) need to figure out once the 'maximum' list of dependent system DLLs.
I missed that one. |
I can and I have, per the link to the commit I posted earlier. I also find this to be a bad developer experience, a point with which you seem to disagree. |
|
Note that I've said before that we store our stuff on a read-only place in a SCM system. That directories do not necessarily have a relationship with the output directories of the mentioned product. My goal is just NOT to build everything any time (as we have multiple developers, who don't want to build the same thing each time), but only build something, if it has changed. And then put the results in a SCM system. Trivially set INCLUDE/LIB was insufficient if I remember well. Please await my further testing next week. BTW: always using /MD has a disadvantage if your are making debug builds. The difference between optimized and debug builds is still useful (so release builds should use /MD and debug builds /MDd). The /Mxxx flags should match with everything else what was built and uses libcurl. You cannot mix these flags. And that is probably why /MT and /MTd also exist (in libcurl makefile) as users may use it (regardless the fact that using static run time DLLs is a very bad idea). Just FYI: my make command for libcurl is (expanded output from a solution/project file): Before my PR, generating PDB files also failed. |
|
My PR was discussed by others as well. I like to hear their opinion. |
|
Yes, debug builds should use |
|
Since you asked: for me,. the problem start here
That's not sufficient for our situation where we require to be able to build 2 targets (architectures) and 2 configuration (debug/free) in an automated manner, and usually in a hurry if theres a secadv out. Further we use the MS standard for file names (targets keep the same lib and dll names, configurations are distinguished). I'm not saying these are correct requirements and I won't defend them but they serve us well. So I'm faced with having to intrude into our dependencies' build environments. I accept this and its costs. In some cases (zlib) and I can automate this, in others (OpenSSL) the intrusion is minimal. In a few cases (Xerces and Santuario) I can get away with black boxing it - everything is available as a supported parameter. Curl is 99% of the way (It's a black box, but I'm using what I consider are reserved behaviors via the My memory is vague, but I'm pretty sure that when when I looked at this I didn't consider that INCLUDE and LIB to be a public API and/or that it wouldn't have helped my build. It wouldn't help with the lib/dll name thing either though so I'm always going have to be "unsupported". I liked @kdekker 's fix because it made me less unsupported. But I'm not going to make a statement in favor one thing or another - this begins to get religious and I gave up religious wars about tech in the 80's. OTOH will check every build change as it hits github to make sure it doesn't break me, and if it does look to see if it can be changed and if not make the changes I need. If curl ships a secadv and I have to scurry I don't need a broken build environment. |
|
The thing I (but also @p) can check is re-add/change line 422 (based on curl/master on github) from: It will then (most probably) not aggregate all (other) static libs, and it may (or may not) add Windows system DLL dependencies (and make libcurl more 'abstract'). I will try to check next week. I'm not sure, but nmake /E option can be used to set e.g. SSL_INC_DIR/SSL_LIB_DIR if the output structure of (in this example a 3rd party SSL lib) does not patch SSL_PATH/include and SSL_PATH/lib. |
|
The other problem that this change caused is the requirement to keep libraries of all of libcurl's dependencies around. Prior to 7.60.0, in order to build software against libcurl one needed libcurl's headers and libraries produced by libcurl's build process, i.e. libcurl.lib or libcurl_a.lib. As of 7.60.0, libcurl_a.lib no longer contains the code that libcurl is statically built against, which means one must manually assemble all of the libraries that libcurl uses and keep those around indefinitely in order to build anything dependent on libcurl statically. https://msdn.microsoft.com/en-us/library/e17b885t.aspx says:
Hence the fix should be as simple as putting back all of the libcurl's dependent libraries on the lib.exe command line, which I can look into if there is agreement that this is the correct path forward. |
Do you mean that aggregating is something that you want? I.e. if you build curl statically, using e.g. openssl, than also the openssl stuff should become part of static libcurl.lib? If you meant that, I'm really surprised, as I don't know another example that is using that way of building. Aggregating other libraries in static libcurl.lib is very strange, as the used other libraries (e.g. libcrypto.lib and libssl.lib) still remain. Using them both with libcurl.lib will then result in duplicate symbols. This is violating separation of concerns as static libcurl.lib should not contain anything aggregated from the other parties. I will not make a PR for this. My PR intentionally removed this dependency to e.g. openssl. See also my comments in both this thread and in makefiles itself (about unwanted aggregation). It seems that you are disagreeing with that. BTW: did you already try out my advise to add WIN_LIBS to the lib command? You can also try out things yourself. |
|
I think the question is: should curl.lib be self-contained, including dependencies to Windows DLLs and incorporating any product configured? For myself: if this is indeed what is wanted with the static curl library, I would be very surprised. There are at least two reasons not to want this:
When looking at other build methods (curl\projects\Windows\VCnn), as far as I can see (because Visual Studio does not add dependencies, since creating a lib does not contain a link step) no dependencies are added for libcurl. So the way you are supposing to be a 'normal' way is IMO very uncommon. I'll await your response before spending more time to this issue. |
|
You keep saying you are experiencing errors and are unable to do certain things, but in this entire time I haven't seen a single error quoted nor any sort of a build configuration. Lacking these details I am not able to respond to your concerns effectively. |
Using 7.59.0 (i.e. prior to this commit), the build raised some warnings (not errors, my mistake), but the pdb files are incorrectly generated (=error). Build procedure:
My directory layout of deps is: I'm not listing the header files here. And note that the pdb files are copied here as well. As visual studio uses vc.pdb (where nnn is a version) as default, then you can see that only one such file can be stored (this one is of libssh2). That is at least one reason to need to have 'other deps in isolated directories'. The output (I only show parts of interest) of the build command (step 3) is: Notes:
But even worse, all is aggregated in curl static lib (and pdb) resulting in a huge (30MB+) lib: So, I hope that you agree that this is incorrect. The benefit for you is that libcurl.lib is 'self-contained', containing all references to anything that is used by curl, but at a price of a unusable pdb file, and a lot of compiler warnings. Using curl 7.60.0, the story becomes different. The make command was kept the same for case of simplicity, same headers and libs of libssh2, zlib and openSSL have been used. The output now becomes: Notes:
And note that aggregation have gone. That's exactly what I want (and what I suppose to be as 'normal'). The generated library has much smaller output. Finally: Using 7.60.0, without adding $(WIN_LIBS) to the lib.exe command (Makefilebuild.vc:422) will result in a libcurl.lib that (of course) don't have dependencies to windows system DLLs. See: Note: curl.exe of course has dependencies to e.g. advapi32.dll. Changing the lib.exe line in Makefilebuild.vc:422, results in a (static) cURL library that has dependencies, but also reintroduces compiler warnings, see below: Finally: I think my PR (almost) solved all of this. Your way of working (by adding system dependencies) to static libraries is - although not raising errors - still strange. I hope that I have convinced you. |
According to what you posted, this is a deficiency of your build process. The final output you are showing contains only the pdb for libcurl - no pdb files for its dependencies - so if this is what you want, don't copy the dependencies' pdb files to your dependency aggregation directory. No changes in libcurl build process are needed.
We already covered that libcurl supported dependencies in their own directories going back to 7.19.0.
This is bad regardless of whether it's a static/dynamic mix or release/debug. You should be referencing /MDd (but can still give /NDEBUG etc.) when building e.g. libssh2 that is used by a debug libcurl. And I'm guessing you do still have the static/dynamic mix in release builds.
Exactly, warnings. So far nothing indicates any need to repair them at the cost of making it difficult to work with libcurl.
I will address this again: if you don't need the other pdb files, don't copy them to where they get in the way. If you do need them, you can rename them since you are copying them. In either case no changes to build process of either libcurl or its dependencies are needed (though renaming pdb files may be handy, I don't know how to do that off the top of my head). To summarize, what I see is you made libcurl's build process do the work that should be performed by you in your organization-specific steps. I understand that either way works for you but it really doesn't for other use cases. |
If you don't know another example in Windows world, that works in this way, then I think that your build process has a deficiency. It has no sense in talking about yours or mines in this case, as the duplicate warnings clearly indicates that this way of working is strange.
Yes and no. In case if 3rd party (static) libs are being used, that come in one (=typical release) form, and you are building your own stuff in debug mode, then you always have this warning (which cannot be solved). It is indeed related to release/debug mode (of referenced msvcrd[d]), but it is typically Microsoft. Other (*NIX) plaforms do NOT need to tell in a own static (sic!) library what kind of runtime will be used. So this (LNK4098) warning can be ignored for this discussion. I don't know how to prevent this one.
Warnings are potentially bugs. So why do you like to ignore (LNK4006) warnings? Solely because it facilitates your build process? And please keep in mind that I've said before that link.exe /lib is undocumented. You should not use or rely on undocumented things neither leave warnings exist. It is IMO laziness to certain extend not to solve warnings. Warnings make noise, and may hide a real issue. Finally: you are right that rolling back this PR also requires me to adjust my build process. But as - I'm repeating myself too often in this thread - none of the other Windows build approaches work in the same way as you are liking/wanting here, I think the current approach is better. I don't like to spend time to rolling back a fix that gives me only additional work to me. If you like to rollback this PR, just feel free to make your own PR and ask the community/maintainers whether they are willing to commit it on the main branch. Based on my feedback in this thread, I think it is strange to do so. |
|
That is exactly what I proposed about a week ago. |
|
For some reason, I believe you don't really listen. If you can find another example that works in the same way as you prefer, I would agree. But at this point, I would be very surprised if a maintainer of curl would accept a PR to rollback this fix. It is then contrary all logic (and IMO common sense). You do not really take my arguments into account (is my feeling). BTW: Some addition about xxx_PATH variables (I forgot to comment on it): using xxx_PATH that points to lib/include subdirs, is quite common (compare with *NIX /usr/lib and /usr/include stuff). And most other products create a /lib and /include structure upon make install. I think the xxx_PATH approach is not that bad. |
|
You of course understand my use case perfectly. |
Allow to provide own locations for zlib, openssl, libssh2, cares.
The link.exe /lib failed, because it added (Microsoft) dependencies. As create a static lib is just aggregating objects into an archive, use lib.exe instead.
As lib.exe does not perform optimizations nor linking, the optimizations and dependent windows libraries should not be provided as flags to the archiver.