Charles Wilson <libtool <at> cwilson.fastmail.fm> writes: > No, what it means is that, IF the project maintainers want to support > shared libraries (DLLs) on win32, then they must do the following -- and > this is true regardless of whether libtool is involved.
I think the real problem is that we differ in our understanding of how the development of a typical project work. You assume that the developers know in advance everything there is to know about Win32 DLLs and libtool but IME this is not always the case, especially for the latter. So while I can't disagree that what you wrote should happen in an ideal case, a more typical scenario is simply that somebody tries to build the project under Windows. If there are undefined symbol errors, they will be fixed and maybe, just maybe, while doing it the person attempting the build will also discover libtool --no-undefined flag but maybe not even then. What is almost certain however is that if there are no undefined symbol errors (which is a rather common case after all) there is going to be much head-scratching because of libtool seemingly unmotivated refusal to build the shared libraries even so. IOW maybe the simplest solution would be to just include a mention of --no-undefined in the warning message given by libtool when it decides to skip building the shared library. E.g. replace the current libtool: link: warning: undefined symbols not allowed in $host shared libraries message with something more user-friendly like this: libtool: link: warning: Skipping the generation of the shared library as undefined symbols are not allowed in $host shared libraries. Use -no-undefined option to allow building it if there are really no undefined symbols. With the current message it's far from clear that libtool isn't going to build the shared library (it just warns about something but doesn't say explicitly what does it mean) nor, most importantly, what can be done about it. > 2) Once you've gone thru the exercise in #1, now you might as well add > -no-undefined unconditionally to your libtool invocation -- if you are > using libtool, that is. Exactly! If you don't use libtool, you don't need to do anything special and can just run the same "g++ -shared ..." command as under Unix provided you don't really have any undefined symbols. But if you do use libtool you need to know to use -no-undefined to prevent libtool from quasi-silently deciding that your shared library can't be built for you. Anyhow, to use the terminology of Peter Rosin's reply, I'm going to resume my efforts to provide a patch to at least fix this for the case (C1). But personally I remain convinced that the current behaviour in case (C3) is very unhelpful. Hopefully at least the warning message could be modified as proposed above to make it slightly less so. Regards, VZ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool