PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se wrote: PR Den 2011-06-23 14:25 skrev Vadim Zeitlin: PR Am I the only one to think that this behaviour is singularly PR unhelpful? PR PR Of course not, others have stated that a patch would be welcome to PR fix --disable-static (and --enable-shared) to error out if it is not PR possible to create a shared library (due to a missing -no-undefined). Sorry for the delay, I got distracted by other things but here is finally the promised trivial patch (I also cc it to libtool-patches just in case, sorry if you get this message twice): From: Vadim Zeitlin vz-libt...@zeitlins.org Date: Thu, 7 Jul 2011 17:26:43 +0200 Subject: [PATCH] Don't fall back to static libraries if building them was disabled. If -no-undefined was not specified but the platform didn't support shared libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were built instead of shared ones, even if building them was explicitly disabled with --disable-static configure option. Fix this by stopping with a fatal error if a shared library can't be built in this case instead of unexpectedly building a static library instead. * libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when trying to build a shared library without -no-undefined on a platform not supporting undefined symbols in shared libraries. Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org --- libltdl/config/ltmain.m4sh |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 8e5c588..40b1d5f 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6735,9 +6735,12 @@ func_mode_link () # Check to see if the archive will have undefined symbols. if test $allow_undefined = yes; then if test $allow_undefined_flag = unsupported; then - func_warning undefined symbols not allowed in $host shared libraries - build_libtool_libs=no - build_old_libs=yes + if test $build_old_libs = yes; then + func_warning undefined symbols not allowed in $host shared libraries + build_libtool_libs=no + else + func_fatal_error can't build $host shared library unless -no-undefined is specified + fi fi else # Don't allow undefined symbols. -- 1.7.2.3 I've tested this patch with the default and --disable-static configurations under Windows and Linux and it behaved as expected. Maybe the error message could be improved but I tried to remain consistent with the existing warning, if this consideration is not important it might be better to be more explicit about the problem and its potential solution. PR But fixing that is a separate issue from what the default behavior PR should be when -no-undefined is not specified. I agree with this but I still disagree that the current default behaviour is useful. IMO both (C1) and (C3) should try to build a shared library even if -no-undefined was not given and simply either stop with a fatal error or fall back to a static library if it failed. I don't see how could getting a shared library in addition to the static one in the case (C3) could ever be a problem and getting the expected result in the case (C1) is definitely an advantage and not a drawback. But I won't discuss this any more as I don't have any new arguments and apparently the ones I already gave were insufficiently convincing. Regards, VZ pgp8oBjQCFcWr.pgp Description: PGP signature
PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)
On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin p...@lysator.liu.se wrote: PR Den 2011-06-23 14:25 skrev Vadim Zeitlin: PR Am I the only one to think that this behaviour is singularly PR unhelpful? PR PR Of course not, others have stated that a patch would be welcome to PR fix --disable-static (and --enable-shared) to error out if it is not PR possible to create a shared library (due to a missing -no-undefined). Sorry for the delay, I got distracted by other things but here is finally the promised trivial patch (I also cc it to libtool-patches just in case, sorry if you get this message twice): From: Vadim Zeitlin vz-libt...@zeitlins.org Date: Thu, 7 Jul 2011 17:26:43 +0200 Subject: [PATCH] Don't fall back to static libraries if building them was disabled. If -no-undefined was not specified but the platform didn't support shared libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were built instead of shared ones, even if building them was explicitly disabled with --disable-static configure option. Fix this by stopping with a fatal error if a shared library can't be built in this case instead of unexpectedly building a static library instead. * libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when trying to build a shared library without -no-undefined on a platform not supporting undefined symbols in shared libraries. Signed-off-by: Vadim Zeitlin vz-libt...@zeitlins.org --- libltdl/config/ltmain.m4sh |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 8e5c588..40b1d5f 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6735,9 +6735,12 @@ func_mode_link () # Check to see if the archive will have undefined symbols. if test $allow_undefined = yes; then if test $allow_undefined_flag = unsupported; then - func_warning undefined symbols not allowed in $host shared libraries - build_libtool_libs=no - build_old_libs=yes + if test $build_old_libs = yes; then + func_warning undefined symbols not allowed in $host shared libraries + build_libtool_libs=no + else + func_fatal_error can't build $host shared library unless -no-undefined is specified + fi fi else # Don't allow undefined symbols. -- 1.7.2.3 I've tested this patch with the default and --disable-static configurations under Windows and Linux and it behaved as expected. Maybe the error message could be improved but I tried to remain consistent with the existing warning, if this consideration is not important it might be better to be more explicit about the problem and its potential solution. PR But fixing that is a separate issue from what the default behavior PR should be when -no-undefined is not specified. I agree with this but I still disagree that the current default behaviour is useful. IMO both (C1) and (C3) should try to build a shared library even if -no-undefined was not given and simply either stop with a fatal error or fall back to a static library if it failed. I don't see how could getting a shared library in addition to the static one in the case (C3) could ever be a problem and getting the expected result in the case (C1) is definitely an advantage and not a drawback. But I won't discuss this any more as I don't have any new arguments and apparently the ones I already gave were insufficiently convincing. Regards, VZ pgpgD5ub1Glcm.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
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
Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 23 Jun 2011, Vadim Zeitlin wrote: BF BF I.e. it created a shared library with undefined symbols without any BF problems because it never actually passed -no-undefined to g++/ld. BF BF In actual practice, it seems difficult or impossible to build programs BF under systems like Linux with -no-undefined. I didn't know this but doesn't this make the situation even worse? I.e. because of the above you can't even recommend people to use -no-undefined by default. So the default behaviour will remain the current one, i.e. no DLLs at all under Windows. BF I have no idea whether -no-undefined is supposed to work like this but in BF any case it seems to me that it's perfectly useless right now. It's not BF BF Not quite useless, but not pedantically useful either. Useless and useful are subjective, of course, but what seems undeniably objective to me is that currently libtool by default doesn't create shared libraries under Windows at all, even with --disable-static (although, again, --disable-static shouldn't be considered as a solution for this) and you need to force it to do it by using -no-undefined explicitly. Moreover, you may need to do this conditionally, for Windows only, as this could break things under Linux apparently. And this drastically reduces libtool usefulness under Windows. To put it in another way, currently libtool supposes that a shared library has undefined symbols by default. There would be nothing intrinsically wrong with this assumption but it results in clearly broken behaviour. So IMO it must be changed. I think that ideally libtool should be capable of determining on its own whether the library has undefined symbols or not. But if/as this is too difficult to implement, for now a more reasonable approach would be to admit that libtool doesn't know whether this is the case and try to do its best with this information and try to create shared libraries under Windows by default. If -no-undefined is explicitly specified it wouldn't then change anything for its behaviour under Windows and similar platforms (AIX?). Finally, some new -has-undefined option might be introduced to explicitly tell libtool that a library really does have unresolved external symbols and so can't be built under Windows. What do you think? VZ pgpNR49pd50KF.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 23 Jun 2011, Vadim Zeitlin wrote: I.e. it created a shared library with undefined symbols without any problems because it never actually passed -no-undefined to g++/ld. In actual practice, it seems difficult or impossible to build programs under systems like Linux with -no-undefined. I tried this before, but glibc got in the way since it depends on some symbols which are never/rarely defined. Under Linux, programs run just fine with undefined symbols as long as they are never accessed. I have no idea whether -no-undefined is supposed to work like this but in any case it seems to me that it's perfectly useless right now. It's not Not quite useless, but not pedantically useful either. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
Den 2011-06-23 14:25 skrev Vadim Zeitlin: On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin p...@lysator.liu.se wrote: PR Den 2011-06-23 11:22 skrev Vadim Zeitlin: PR I have no idea whether -no-undefined is supposed to work like this but in PR any case it seems to me that it's perfectly useless right now. It's not PR checked at all under normal Unix systems so it can't be used to ensure that PR a shared library actually doesn't have any undefined symbols and so could PR be created under Windows too. And it must be always specified under PR Windows as otherwise DLL are never created at all. PR PR If you really are targeting Windows (or some other platform which needs PR -no-undefined to build libtool libraries) then you really do get a failure PR if there are undefined symbols. Yes but *only* if you had -no-undefined in your Makefile.am. If you do not specify -no-undefined, you practically silently (not quite as it does output libtool: link: warning: undefined symbols not allowed in $host shared libraries but this is very easy to miss) get a static library instead, whether there are any undefined symbols or not. This is even worse than the original problem that I had because at least you had a big fat warning with plenty of asterisks in that case because there was another problem in that case. But if all goes perfectly well you still never get a shared library without no-undefined. Even if you specified --disable-static as you did in my example (although IMO even without it silently creating static library when a shared one was requested is wrong). Am I the only one to think that this behaviour is singularly unhelpful? Of course not, others have stated that a patch would be welcome to fix --disable-static (and --enable-shared) to error out if it is not possible to create a shared library (due to a missing -no-undefined). But fixing that is a separate issue from what the default behavior should be when -no-undefined is not specified. The think the push- back you are sensing is because you are mixing those two issues. The thing is, if you really do have undefined symbols, *and* are targeting Windows (or other platforms needing -no-undefined for normal libraries), there is no (clean simple) way to explicitly declare that you don't want libtool to attempt to build the shared lib, you can only implicitly declare that fact by *not* specifying -no-undefined. At the same time, you want failures to be reported back and interrupt the build, for cases where you really do hit undefined symbols. Let me attempt to line up all the cases: A. We know that there are no undefined symbols, -no-undefined is specified. B. We know that there are undefined symbols, -no-undefined is not specified. C. Noone has bothered to check for undefined symbols, package was never ported to Windows, -no-undefined is not specified. 1. --disable-static in effect 2. --disable-shared in effect 3. Build both static and shared, or whatever is possible. For A1 and B1 we want to error out on Windows if we can't find shared versions of all dependencies, because we do not want to risk including static libs in the resulting shared lib, and we don't want to fall back to a static lib since a shared lib was explicitly requested. IMO there is a bug for this case, since currently libtool falls back to creating a static lib when it can satisfy missing symbols with static dependencies. You also think this is a bug, and I don't think anyone disagrees with you, me, Bob and Chuck that it really is a bug. For A2, B2 and C2, there is no problem, you get a static lib. For A3 and B3, there is no problem, but you don't get a shared lib on Windows (as desired, don't want to risk static dependencies inside the shared lib). For C1, it would perhaps be nice to go looking for shared versions of all dependencies and then attempt to link the library and fail if any of that didn't work out. But see below (-*-). For C3, I can agree that libtool *could* look for shared versions of all dependencies and if found, libtool *could* attempt to create the shared lib, hoping that there would be no undefined symbols. I.e. just as in C1, but then not error out if any of that fails but instead just ignore the failure and proceed with a static-only result as if nothing happened. But I must say that it would be kind of surprising to one day get both a static lib and a shared lib, and the next day silently only get a static lib because some bozo broke something (completely unrelated) for Windows. True, the bozo code would perhaps fail on Windows for the static case as well, but maybe not. And since it is a bit fragile to make that shared attempt for the C3 case, it would be quite surprising if the C1 case (-*-) did succeed in creating a shared lib, but C3 didn't. PR Quoting the docs for the libtool -no-undefined option: ... PR I.e. no mention of any actual check if there were any undefined PR symbols. I agree that the
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote: On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 23 Jun 2011, Vadim Zeitlin wrote: BF BF I.e. it created a shared library with undefined symbols without any BF problems because it never actually passed -no-undefined to g++/ld. BF BF In actual practice, it seems difficult or impossible to build programs BF under systems like Linux with -no-undefined. I didn't know this but doesn't this make the situation even worse? I.e. because of the above you can't even recommend people to use -no-undefined by default. So the default behaviour will remain the current one, i.e. no DLLs at all under Windows. 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. 1) Ensure that when building for win32, that the various object files that will be combined into the DLL, as well as the library dependencies (-lwhatever) are such that there WILL BE no undefined symbols, at least *when building for win32*. Otherwise, ld will refuse to create the DLL. This may involve restructuring the code, and possibly changing the division of labor between various DLLs if your project has multiple interdependent ones. It is *very* difficult to build stuff on win32 where you have circular dependencies between DLLs, or between DLLs and an EXE -- not impossible, just very difficult. (*) Now, if you are going to go thru all that trouble to support win32...you'd just be making a lot of extra work for yourself to maintain TWO separate library structures -- one for win32 (and, btw, AIX) where everything is no undefined symbols clean, and one for everything else where undefined symbols are allowed. So...most projects that end up in this place (**), finally decide to restructure their shared libraries for *ALL* platforms. Notice I haven't said anything about libtool yet. 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. Remember, all the stuff in #1 is required just to build DLLs on win32 *at all*, libtool or no libtool. (*) You basically have to create an export file for DLL A (or the EXE), and an import lib for it. THEN, you can build DLL B as normal, and specify -lDLLA (or -lEXE). Finally, you build the real DLL A (or EXE), and specify -lDLLB. Libtool has /no/ direct mechanism to support this. (**) Except for those that use a plugin architecture, where the plugin DLLs *must* be able to call back to the EXE. That's really tricky, and they usually end up using another solution, of which there are several (see http://edll.sourceforge.net/ for a good description of several different approaches). But that's outside the scope of our discussion here. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
Charles Wilson libtool at cwilson.fastmail.fm writes: A more interesting question is if the current situation with libtool can be improved because I continue to believe that getting a static library when you're trying to build a shared one can be very unexpected. And this can be the case even under Unix where there would be presumably too much resistance to change the way --disable-static works if it is controversial even under Windows where I thought it would be obviously correct. So it seems the only solution with any chance of acceptance would be to add a different option doing what I want, e.g. --enable-shared-only. Or maybe allow --enable-shared=(yes|no|only)? No, I think --disable-static, if specified, should actually *disable static*. That should be sufficient. If it's not doing that, then it's a bug IMO. Just to confirm: no, currently it doesn't do this. The example of my original message came from libxml2 build configured with --disable-static. So should I try to create a patch making libtool fail in this case? Thanks, VZ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 5:49 PM, Charles Wilson wrote: On 6/17/2011 11:03 AM, Marco atzeri wrote: Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the detection fails? Maybe we can figure out why func_win32_libid() is failing. -- Chuck Hi Chuck, I guess func_win32_libid() is not failing but the gcc/linker is smarter than libtool expect; or that autoconf is misleading libtool. At configure stage for checking for Fortran 77 libraries of gfortran-4 configure:28653: result: -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 And on Makefile FLIBS = -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 Now in the gfortran package: /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la libgfortran is available as dynamic and static, while libgfortranbegin is only static libgfortranbegin.a is included as object in the build of the dll/exe, while libgfortran.dll.a is used for the linking with cyggfortran-3.dll Similar thing happens for the few libraries that are available only as static like SuiteSparse checking for ccolamd in -lccolamd result: yes so CCOLAMD_LIBS = -lccolamd But Suitesparse libs are only static: /usr/lib/libamd.a /usr/lib/libbtf.a /usr/lib/libcamd.a /usr/lib/libccolamd.a /usr/lib/libcholmod.a /usr/lib/libcolamd.a /usr/lib/libcsparse.a /usr/lib/libcxsparse.a /usr/lib/libklu.a /usr/lib/libspqr.a /usr/lib/libumfpack.a so they are included as objects in the dll build. For your notice, building octave with lt_cv_deplibs_check_method=pass_all works fine and the program pass all the tests, while without it the program is unusable. Regards Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/20/2011 3:32 AM, Marco atzeri wrote: Hi Chuck, I guess func_win32_libid() is not failing but the gcc/linker is smarter than libtool expect; or that autoconf is misleading libtool. /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la libgfortran is available as dynamic and static, while libgfortranbegin is only static libgfortranbegin.a is included as object in the build of the dll/exe, while libgfortran.dll.a is used for the linking with cyggfortran-3.dll Hm. This is a big, general problem: it means you libtool can't build ANY fortran DLLs -- because they will all need libfortranbegin.a IIRC, the fortran startup object used to be *an object*, so it didn't trigger this problem. We're really collecting more and more reasons to rewrite the support in libtool for the gcc compiler to just use $(CC) (or $CXX, etc) to link, and NOT muck around with detecting all these objects and compiler runtime libs and crud -- which we currently do so that libtool can link using $(LD) directly. Now, even if we DID do that, it won't fix the problem below: Similar thing happens for the few libraries that are available only as static like SuiteSparse checking for ccolamd in -lccolamd result: yes so CCOLAMD_LIBS = -lccolamd But Suitesparse libs are only static: /usr/lib/libamd.a /usr/lib/libbtf.a /usr/lib/libcamd.a /usr/lib/libccolamd.a /usr/lib/libcholmod.a /usr/lib/libcolamd.a /usr/lib/libcsparse.a /usr/lib/libcxsparse.a /usr/lib/libklu.a /usr/lib/libspqr.a /usr/lib/libumfpack.a so they are included as objects in the dll build. Well, in this case, libtool is doing what it is programmed to do: don't allow DLLs to depend on static libs. As I said earlier, this is in general a good rule for win32. You've found a case where this heuristic fails, and violating it does not /appear/ to cause any problems for this particular application. I think, in this case, overriding the autoconf variable as you are doing is actually the right procedure! I'm leery of making this a configure option (--allow-static-deps) because then the uninitiated might use it all the time...and invariably they WILL run into the problems I warned about. For your notice, building octave with lt_cv_deplibs_check_method=pass_all works fine and the program pass all the tests, while without it the program is unusable. But we still have the problem with fortran DLLs in general. Sigh. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote: On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF Most projects using libtool come from Unix/Linux where auto-import BF is the default so it can be seen that most projects already depend on BF it My personal experience seems to contradict it. Maybe because auto-import is relatively recent It was developed back in 2000, and all cygwin and mingw compilers since that date have supported it, EXCEPT for the old msys gcc-2.95.1 toolkit which was used to create *msys* executables up until 2009. or maybe because most originally Unix projects that target Windows (meaning not only Cygwin but usually MinGW as well and sometimes even MSVC) need to fix other Windows-specific issues anyhow and so do make the relatively small extra effort to add the necessary declspecs too. This. IF -- and usually ONLY if -- the upstream maintainers have ported to *msvc* FIRST, then they have added the declspec stuff. Then, when it comes to supporting mingw, they have a choice: do things the unix way and DON'T activate the declspec stuff and use autoimport instead, OR, do things the MSVC way. My experience has been that this decision usually goes the win32 way, but a significant fraction go the unix way for mingw. The alternate path is this: the upstream maintainers port to mingw FIRST, and fix the obvious things like using _mkdir(one arg) instead of mkdir(two, args) -- but don't want to uglify their headers with declspec. THEN, they port to msvc and are forced to uglify. At that point, they have a new choice: do they retrofit the declspec stuff for their existing mingw build, or not. Most do not. Obviously, packages developed originally on/for windows have the declspec stuff, and usually keep it turned on for msvc and mingw. Anyhow, this is purely anecdotal and it's going to be hard to find an objective way of determining whether it's the case. True. A more interesting question is if the current situation with libtool can be improved because I continue to believe that getting a static library when you're trying to build a shared one can be very unexpected. And this can be the case even under Unix where there would be presumably too much resistance to change the way --disable-static works if it is controversial even under Windows where I thought it would be obviously correct. So it seems the only solution with any chance of acceptance would be to add a different option doing what I want, e.g. --enable-shared-only. Or maybe allow --enable-shared=(yes|no|only)? No, I think --disable-static, if specified, should actually *disable static*. That should be sufficient. If it's not doing that, then it's a bug IMO. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 2:10 AM, Bob Friesenhahn wrote: On Fri, 17 Jun 2011, Vadim Zeitlin wrote: Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the traditional Windows way and have trouble accepting auto-import magic. It's true that projects using auto-import could live with falling back to a static library. But consider that auto-importing is relatively new so there should be proportionally few projects using it, hence IMHO the risk of breakage remains reasonably small. Most projects using libtool come from Unix/Linux where auto-import is the default so it can be seen that most projects already depend on it (and the main issue for them is to use --no-undefined so libtool will build a DLL). Primarily programs which originated under Windows (or really care about Windows) use the dllexport/dllimport facilities. Bob Bob, Vadim, on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It made me crazy building octave where the DLL dependency list is very very long. Regards Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
Den 2011-06-17 01:15 skrev Bob Friesenhahn: On Thu, 16 Jun 2011, Vadim Zeitlin wrote: BF BF In what way was libtool specifically requested to build a DLL? I'm not sure about the details (please keep in mind that we're speaking about libxml2 here and not my own project) but configure[*] is passed --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as meaning that [only] shared libraries should be built, isn't it? It does seem like falling back to building a static library when --disable-static has been specified is a bug. IOW I don't think an example when proceeding ahead is a viable solution is possible. Do you have anything concrete in mind? As it happens, GCC under MinGW and Cygwin does have an auto-import facility which magically allows it to work for code built with GCC. Explicit dllexport/dllimport is not needed. It does not work for MSVC and might not work if GCC is linking against a MSVC-built DLL/library. Hrmm, hrmm, allow me to step into this conversation and make a note that there are libraries that work just fine in all kinds of ways when built with MSVC. Libtool can with those libraries produce both a static and a shared library and you can write applications that need not know, at compile time, if they are going to be linked with the shared or the static library. And it's not that difficult either. Heck, I can do it :-) Granted, you will probably(?) take an extra pointer dereference if you are actually linking with the static library, but it works. The libtool testsuite would have more fails with MSVC if this was not the case. BF If libtool simply refuses to proceed, then many applications will fail BF to build and users will also be unhappy. Again, I don't think such change could break anything because applications that would rely on this behaviour wouldn't build even right now. I have experienced such issues before but my own application did still build and work. A library which is expected to be loaded by another program such as a DLL or loadable module would obviously be broken by static linkage. Yes, I agree, there are obviously cases where a static lib does not fill the shoes of a shared lib... Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 4:14 PM, Charles Wilson wrote: On 6/17/2011 3:46 AM, Marco atzeri wrote: on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It's not about system capabilities in this case. It's about the fact that this -- creating a shared library by linking against existing static libraries -- is a really bad idea. If any of those static libs (a) exports a data item, and (b) is used by more than one DLL in your stack, then you'll end up with two different copies of the data item, and one DLL will use the first copy while the other DLL will use the second copy. Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. I know that octave on cygwin is an extreme case due its number of dependencies, but it is not the only case. Of course my knowledge of libtool is limited and eventually there is another way but I never found it. -- Chuck Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 11:03 AM, Marco atzeri wrote: Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the detection fails? Maybe we can figure out why func_win32_libid() is failing. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011, Vadim Zeitlin wrote: different functions (_foo vs _imp__foo). So IMO creating a static library when libtool was requested to build a DLL is never the right thing to do under Windows. And while I hesitate to call this behaviour a bug because it is clearly intentional, I'd like to see it changed because it would have saved me (and presumably others) a lot of time if libtool simply stopped with an error after giving the above message instead of valiantly but ultimately counterproductively trying to continue. In what way was libtool specifically requested to build a DLL? There are certainly cases where proceeding ahead with a static library is a viable solution. If libtool simply refuses to proceed, then many applications will fail to build and users will also be unhappy. What happens if you specify --disable-static to configure? Does that help? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011 15:36:24 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 16 Jun 2011, Vadim Zeitlin wrote: BF different functions (_foo vs imp_foo). So IMO creating a static library BF when libtool was requested to build a DLL is never the right thing to do BF under Windows. And while I hesitate to call this behaviour a bug because it BF is clearly intentional, I'd like to see it changed because it would have BF saved me (and presumably others) a lot of time if libtool simply stopped BF with an error after giving the above message instead of valiantly but BF ultimately counterproductively trying to continue. BF BF In what way was libtool specifically requested to build a DLL? I'm not sure about the details (please keep in mind that we're speaking about libxml2 here and not my own project) but configure[*] is passed --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as meaning that [only] shared libraries should be built, isn't it? BF There are certainly cases where proceeding ahead with a static library BF is a viable solution. Sorry, I can't agree with this when speaking about _Windows_ libraries. While under a typical Unix system you can link a program with either static or shared library without changing anything in its code, this is not the case under Windows as you must either use __declspec(dllimport) or equivalent or not use it (usually this is governed by some preprocessor symbols similar to libxml2 LIBXML_STATIC so you need to either define or not define it). So if the project expects to link with a DLL, producing a static library is not helpful as linking with it would still fail -- and in fact this is exactly what happens in my case. Notice that, on the contrary, if the project can link with a static library then it wouldn't be able to link with a DLL and so it wouldn't be trying to build it using libtool in the first place. IOW I don't think an example when proceeding ahead is a viable solution is possible. Do you have anything concrete in mind? BF If libtool simply refuses to proceed, then many applications will fail BF to build and users will also be unhappy. Again, I don't think such change could break anything because applications that would rely on this behaviour wouldn't build even right now. BF What happens if you specify --disable-static to configure? Does that BF help? No, --disable-static is already used, in fact, sorry for failing to mention it in my original message. Thanks for your reply, VZ [*] See http://git.gnome.org/browse/libxml2/tree/configure.in pgp4tAgyL34BD.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011, Vadim Zeitlin wrote: BF BF In what way was libtool specifically requested to build a DLL? I'm not sure about the details (please keep in mind that we're speaking about libxml2 here and not my own project) but configure[*] is passed --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as meaning that [only] shared libraries should be built, isn't it? It does seem like falling back to building a static library when --disable-static has been specified is a bug. IOW I don't think an example when proceeding ahead is a viable solution is possible. Do you have anything concrete in mind? As it happens, GCC under MinGW and Cygwin does have an auto-import facility which magically allows it to work for code built with GCC. Explicit dllexport/dllimport is not needed. It does not work for MSVC and might not work if GCC is linking against a MSVC-built DLL/library. BF If libtool simply refuses to proceed, then many applications will fail BF to build and users will also be unhappy. Again, I don't think such change could break anything because applications that would rely on this behaviour wouldn't build even right now. I have experienced such issues before but my own application did still build and work. A library which is expected to be loaded by another program such as a DLL or loadable module would obviously be broken by static linkage. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[3]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011 18:15:01 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 16 Jun 2011, Vadim Zeitlin wrote: BF BF BF BF In what way was libtool specifically requested to build a DLL? BF BF I'm not sure about the details (please keep in mind that we're speaking BF about libxml2 here and not my own project) but configure[*] is passed BF --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as BF meaning that [only] shared libraries should be built, isn't it? BF BF It does seem like falling back to building a static library when BF --disable-static has been specified is a bug. I didn't think about it from this point of view but now that I do, I can't help but agree with you ;-) BF IOW I don't think an example when proceeding ahead is a viable solution is BF possible. Do you have anything concrete in mind? BF BF As it happens, GCC under MinGW and Cygwin does have an auto-import BF facility which magically allows it to work for code built with GCC. Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the traditional Windows way and have trouble accepting auto-import magic. It's true that projects using auto-import could live with falling back to a static library. But consider that auto-importing is relatively new so there should be proportionally few projects using it, hence IMHO the risk of breakage remains reasonably small. Anyhow, logically I think there are 3 possible behaviours for libtool: 1. Build static library. 2. Try to build shared library but fall back to static if it failed. 3. Build shared library and give an error if it failed. As you wrote, --disable-static would seem to imply (3). If (2) is really wanted (and I'm still sceptical about it as the set of projects using auto-import and for which building a DLL is expected, for some reason, to fail should be very small) it seems like another option is needed, e.g. --prefer-shared, to choose it. Regards, VZ pgpDjG6HV5XKB.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[3]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Fri, 17 Jun 2011, Vadim Zeitlin wrote: Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the traditional Windows way and have trouble accepting auto-import magic. It's true that projects using auto-import could live with falling back to a static library. But consider that auto-importing is relatively new so there should be proportionally few projects using it, hence IMHO the risk of breakage remains reasonably small. Most projects using libtool come from Unix/Linux where auto-import is the default so it can be seen that most projects already depend on it (and the main issue for them is to use --no-undefined so libtool will build a DLL). Primarily programs which originated under Windows (or really care about Windows) use the dllexport/dllimport facilities. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
