Re: per-deplib static/dynamic flags
On Thu, 2 Feb 2006, Ralf Wildenhues wrote: I would love to be able to supply LDFLAGS options to configure and have them work appropriately within the configure script, and then work similarly for libtool. Note that `-Wl,-Bstatic' will *not* be useful in LDFLAGS, but LIBS at best, because of the ordering issues. Minor issue. No complaints here! If the options do not work in LDFLAGS, then it will be necessary to pass them explicitly via the Makefile. In this case -Wl,-Bstatic may work better even though it is more obtuse. I don't see any reason against supporting both -force-static and -Wl,-Bstatic as two names for the same thing. I like that. There are likely linkers which will reject -Wl,-Bstatic, but at least it provides an opportunity for success with configure. In the future, we should discuss some way to support pre-processing of options passed to the configure script so that configure tests work as closely to libtool as possible. I don't know how to address that now. By the way, I'd like to fix ordering issues for `-Wl,'-given flags that we don't understand, too; there have been several bug reports about this. Order is often quite important. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: per-deplib static/dynamic flags
Hallo Ralf, Ralf Wildenhues wrote: This fixes the failure uncovered by the new tests posted previously. OK to apply? Looks good to me! Please go right ahead :-) * libltdl/config/ltmain.m4sh (func_mode_link): Fix logic for adding run paths to also add paths for installed libtool libraries in case `-static' is used. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: per-deplib static/dynamic flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | | Hmm. If we were to invent new flags, I currently like | -force-static, -prefer-shared | best. | | |Note though that Ralf has -Bstatic defined as: |If @var{output-file} is a program, prefer linking statically |^^ | |This is not -Bstatic under Linux according to ld(1). If this is what |is intended, then -prefer-static is back :) | | | This is precisely and only because I wasn't sure whether we would find a | linker which allows to set the preferred more but not force it to. | The odcctools http://www.opendarwin.org/projects/odcctools linker has a - -Bstatic/-Bdynamic flag that sets preferred, but does not force it. However, since this linker is probably only used by people cross-compiling a darwin targetted gcc, it can probably be ignored :) Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ+IRY7iDAg3OZTLPAQL+pgQAuwg9Eq4iJGRsZLLvXBmwkKBPZseI0a+C t5hfnE6hhYLr56WqEuaa8KGv4w5e7yilRQT1qv+rhhW61evtIxZnLZ9rwhhB1iRO SoWGt/c29qaXd+Zik52WLPSyVEekykvOOJjLvcDcZlxZnxETri8JOFVBxB2tS5dh u7a+vKeVa2Q= =NhEY -END PGP SIGNATURE-
libtool-2.0 release [WAS per-deplib static/dynamic flags]
Hallo Ralf, Bob, Peter, Eric, Is this patch really necessary for 2.0? I think that introducing so much code churn in to libtool at this stage is going to bring yet more release delays. Surely the feature is useful and desireable, but I really *really* want to avoid more delays for 2.0. Now is the time to branch! Either a feature branch for developing the per-deplib feature for merging after 2.0, or else a 2.0 branch that we can keep stable. My preference is to make a feature branch now, and not branch for 2.0 at least until the release blockers are resolved, so that we can commit any bugfixes we discover during testing just once (we went through the mess of porting to three branches during the last branch-2-0 debacle, and I don't want to do that again!). According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the three remaining release blockers for 2.0 are: * ! libtool.m4 macro ordering/requirement audit. pending * ! LT_WITH_LTDL should build libltdl by default; currently nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE is also given. * ! fix potential denial of service with compilers that do not understand -c -o. * not very likely to happen * http://lists.gnu.org/archive/html/libtool-patches/2005-03/msg00252.html And I would even dispute whether the first of those is really a release blocker -- the code *does* need an audit, but it's been in that state for several existing releases already. lists.gnu.org and mail.gnu.org appear to be down, so I can't read the post attached to the final blocker to remind myself of that issue. So here are the action points, initialed where I plan to take them pending agreement from (most of) you guys. 1. strike the macro ordering audit from the release blocker list. GVV 2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD. GVV 3. make a per-deblib-branch for these changes. 4. evaluate whether -c -o DoS is a release blocker too. 4a. fix it if it is 4b. strike it from the blocker list if it isn't 5. test like crazy. and fix any platform issues uncovered GVV 6. release libtool-2.0 already! GVV Once 2.0 is finally out, I will take a back seat with libtool for a while to work on m4-2.0 and my new book. Ralf Wildenhues wrote: Hi Bob, Albert, * Bob Friesenhahn wrote on Wed, Feb 01, 2006 at 07:47:51AM CET: On Tue, 31 Jan 2006, Albert Chin wrote: On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. At least for the static case, I would prefer the link to entirely fail if a static library is requested but one can not be found. Usually there is a very important reason to use a static library if it has specifically been requested. So the wording should not be 'prefer' for the static case. I agree that the -B syntax does not fit the style of other libtool options (but does match many linkers). Several different issues here: - the option naming, which I will not delve into in this post, and - whether what I'll call -Bstatic for now should fail if it does not find a static library to link against. The latter point is intricate, and requires much more elaboration to be completely specified. That's the main reason I kept the semantics so vague in my proposal. The issues are: library search algorithm, difference between libtool and non-libtool libraries, linker capability. 1) The linker may not allow to specify per-deplib linkage at all, or may not have a flag to force static linkage (as opposed to only _prefer_ it). Examples for the former are Darwin; I haven't found an example for the latter yet (good!). But this means, that for non-libtool libraries we cannot guarantee a certain linking mode, unless we were to change our search algorithm quite drastically (which I don't see as an option ATM). 2) Difference between libtool libraries (*.la) and non-libtool ones, and libtool search algorithm and native linker search algorithm. The current libtool library search algorithm looks a bit like this (before my patch): - given `path/to/libfoo.la', that is taken and nothing else. - given `path/to/libfoo.a' ($libext), that is taken and nothing else. - given `-lfoo' for all searchdirs that we look at, for the extensions `.la', `$std_shrext', `.so', `.a' [1] check whether there exists a file libfoo.$extension if yes, exit search algorithm My patch skips `$std_shrext' and `.so' when in Bstatic mode, but it still happily picks the first `.la' file it can find, even iff that one was shared-only, for example. Currently it then links shared
Solaris/64: wrong sys_lib_search_path_spec (was: libtool-2.0 release)
Hi Bob, * Bob Friesenhahn wrote on Thu, Feb 02, 2006 at 07:38:13PM CET: On Thu, 2 Feb 2006, Bob Friesenhahn wrote: I have also noticed some disturbing leakage of default compiler (GCC) path information into the build which causes -m64 to not work properly (at least under Solaris, but seems likely to impact other targets as well). This bug did not used to exist on the 2.0 branch. In my test case, the compiler is always run via a shell script wrapper (gcc-64) which always runs gcc with -m64 so I am not sure what libtool did to encourage gcc to undo the effect of that option. In order to clarify this issue some more, the problem only happens when linking a C++ library and occurs because while libtool does link using the C++ compiler, it supplies the options '-shared -nostdlib' and then proceeds to tell the compiler what it should already have done by default except that it gets something wrong and passes the path to the 32-bit version of libstdc++.so rather than the 64-bit version the compiler would have used when given the -m64 option. So I think that it is wrong for libtool to be specifying -nostdlib and that it would be more reliable to allow the compiler to find its own crt objects and libraries. The operation may be a vestige of when C++ libraries were linked directly using ld, except that this problem did not occur a year ago so it has somehow been added since then. Nope, but thank you very much for both your patience and your work on this issue. AFAICS this is really Solaris specific: gcc -m64 -print-search-dirs will happily print the 32bit search directories, but not the names of the `sparcv9' subdirectories. This means we have to fix this snippet of libtool.m4: | if test $withGCC = yes; then | sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP ^libraries: | $SED -e s/^libraries:// -e s,=/,/,g` | if $ECHO $sys_lib_search_path_spec | $GREP ';' /dev/null ; then | # if the path contains ; then we assume it to be the separator | # otherwise default to the standard path separator (i.e. :) - it is | # assumed that no part of a normal pathname contains ; but that should | # okay in the real world where ; in dirpaths is itself problematic. | sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e 's/;/ /g'` | else | sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g` | fi | else | sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib | fi or add a Solaris specific addon to the system-specific stuff below. Do you know if GCC will search _only_ $dir/sparcv9 in the list or first all $dir/sparcv9 directories and then then above? The fix should probably not change the directory name if it already ends in sparcv9 -- GCC might fix this eventually. I even vaguely remember that this may be a reported bug; it would be nice if somebody could report it otherwise. And BTW, not passing `-lstdc++' won't work as that will kill dlopening. Cheers, Ralf
Re: libtool-2.0 release
Hi Gary, Gary V. Vaughan writes: Is this patch really necessary for 2.0? No. I think that introducing so much code churn in to libtool at this stage is going to bring yet more release delays. Surely the feature is useful and desireable, but I really *really* want to avoid more delays for 2.0. OK. Now is the time to branch! Either a feature branch for developing the per-deplib feature for merging after 2.0, or else a 2.0 branch that we can keep stable. No way, without me. I outright refuse to maintain another branch. It's insane. It makes more work for us and causes the resulting code to receive less outside testers per branch. However, I have absolutely no problem with delaying the application of the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2. Although we should still commit both the `-static' hardcoding fix and the static.at test patch (the latter is written so that it works also without the per-deplibs-flags patch; it needs only -static-libtool-libs). My preference is to make a feature branch now, and not branch for 2.0 at least until the release blockers are resolved, so that we can commit any bugfixes we discover during testing just once (we went through the mess of porting to three branches during the last branch-2-0 debacle, and I don't want to do that again!). Right. So we put this off, and don't apply it anywhere right now. According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the three remaining release blockers for 2.0 are: The list is outdated. * ! libtool.m4 macro ordering/requirement audit. pending This is as good as done. Forget about it. I have a list of remaining issues (not with me right now), and I will get to it eventually, but am pretty sure those issues are not important to many users. * ! LT_WITH_LTDL should build libltdl by default; currently nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE is also given. I don't even know what this means. I'd guess we should ignore it? * ! fix potential denial of service with compilers that do not understand -c -o. * not very likely to happen I don't mind postponing that to after 2.0, iff that is _not_ responsible for bugs like this one: http://bugs.debian.org/350989 . I have replied there, BTW. HOWEVER. - The regressions that happened in 1.5.22 need to be fixed in 2.0, IMHO (most notably the OpenBSD failure; and good would be the application of the `-static-libtool-libs' patch for users that need the other `-static' semantics; together with the hardlinking regression that I also found for `-static'). - And my outstanding patch-6 needs to be split up and applied. It fixes most but not all remaining issues with HEAD libtoolize. - I know about a couple more tweaks necessary for HEAD libtoolize and Bob has a couple of failures I (or somebody else) need to track down. - AC_PROG_SED may not be AC_DEFUNed (for aclocal 1.6?), and LT_AC_PROG_SED should be catered for. - Makefile.am rules somewhere use GNU make 3.80 features. I have encountered many difficulties preventing autotools reruns on other systems, and am quite fed up with hunting these down. - I have a pending Solaris/whole_archive_flag_spec patch, fixing a regression, and to make libtool work on Solaris 10. So here are the action points, initialed where I plan to take them pending agreement from (most of) you guys. 1. strike the macro ordering audit from the release blocker list. GVV 2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD. GVV OK. Whatever that may be. You webpage does not seem accessible at the moment. 3. make a per-deblib-branch for these changes. Do not make a branch. Pretty please. 4. evaluate whether -c -o DoS is a release blocker too. 4a. fix it if it is 4b. strike it from the blocker list if it isn't See above. I have a half-baked fix lying around somewhere, but will post only after many tests. 5. test like crazy. and fix any platform issues uncovered GVV If I haven't made it clear yet: that is what I've *really* been doing. The static test was the aim, and the bulk of the work, the per-deplibs flags and the `-static' hardcoding fix were the fallout. And I have several more tests which I would like to write or have already started. For example: I would like comprehensive exposure of -L path issues in order to fix the OpenBSD link `-L path order issue' right, so that it does not turn into another regression on another system. I know you would rather release. There is a trade off: better test exposure vs. release delay. My being fed up with working on bootstrap and similar issues that were mostly introduced by the great code reorganizations, and also there being very few test suite contributors and people working on bug reports, has led me to work on the former. Libtool will only get consistently better with a testsuite that exposes much more issues. And if you then