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
Re: libtool-2.0 release
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf!
> Gary V. Vaughan writes:
>> 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.
Agreed. My aim is to not churn the code that will be released any more
than necessary, and I suggested branching to give you somewhere to commit
your patch without the code churn... since you're happy to maintain your
patch outside of CVS for a while, I concur that branching is way more
work than necessary.
> 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).
Agreed. The more tests we commit, the better. I think adding tests that
will fail due to known bugs in the release is okay too... we just mark
them XFAIL until the known bug is fixed after the release.
>> According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
>> three remaining release blockers for 2.0 are:
>
> The list is outdated.
Bummer :-(
>> * 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.
Okay, moved to 'fixed'.
>> * 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?
It means that LT_WITH_LTDL in configure.ac that mentions neither
LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all.
I have a start to a fix for this.
>> * 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.
Okay. I'll leave it on the list as is until you determine whether to
postpone or not.
> HOWEVER.
>
> - The regressions that happened in 1.5.22 need to be fixed in 2.0,
Agreed.
> 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')
I agree that fixing regressions is necessary. I'm not sure that we
need to delay the release for new features... Can you amend the RoadMap
to reflect your thinking on this please?
.
> - And my outstanding patch-6 needs to be split up and applied.
> It fixes most but not all remaining issues with HEAD libtoolize.
Agreed.
> - 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.
Agreed. If you put them on the RoadMap, I might get to them before you.
> - AC_PROG_SED may not be AC_DEFUNed (for aclocal < 1.6?), and
> LT_AC_PROG_SED should be catered for.
D'oh! I have a patch for this already :-/ I'll post it presently.
> - 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 haven't tripped over those yet.
> - I have a pending Solaris/whole_archive_flag_spec patch, fixing a
> regression, and to make libtool work on Solaris 10.
Cool! Please add an entry to the RoadMap.
>> 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
Done.
>> 2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD. GVV
>
> OK. Whatever that may be. You webpage does not seem accessible at the
> moment.
Yeah, my ISP seems to give me 10 min outages once or twice a week... or else
my new modem takes that long to notice the dropped connection from the
ISP end and redial. Sorry about that :-(
>> 3. make a per-deblib-branch for these changes.
>
> Do not make a branch. Pretty please.
Strongly agreed!
>> 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.
Okay. But please let us know whether you're h
Re: libtool-2.0 release
* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 03:43:11PM CET: > > [Is the personal Cc: okay? The list lag is so long that I've gotten into > the habit of Cc:ing you back in so you don't have to wait half a day to > get this.] Yes, surely. There was one point in time where I fixed my gnu.org subscriptions to do what I want for my mail setup, and since then I could stop bothering about this for mails sent to me. List lag is interesting though: it can vary between several hours and less than a minute within the time frame of 12 hours. I am at a loss how to explain this, maybe it's fast when the US-based spammers go to sleep. ;-> > > > It means that LT_WITH_LTDL in configure.ac that mentions neither > > > LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all. > > > I have a start to a fix for this. > > > > Well, so is that really a bug? > I originally wrote LT_WITH_LTDL as a convenience wrapper for AC_LIB_LTDL > in CVS M4, and realised that it was useful enough to almost all clients > of libltdl that it should probably belong in the Libtool distribution... > There is definitely a documentation bug (added to RoadMap) that it is > still undocumented. It's not LT_WITH_LTDL that is undocumented. LTDL_INIT is. > The real question then is whether LT_WITH_LTDL alone > should be equivalent to LTDL_CONVENIENCE plus LTDL_INIT (overridable > with LTDL_INSTALLABLE) or whether it should be *in addition* to all that. Right. > I'm leaning toward the former, but either way the current situation of > being like LTDL_INIT plus --with-ltdl processing is counter-intuitive. > I'll post a documentation patch to help us define the semantics clearly, > and then fix the code to implement what we decide upon. Good. > >>> - 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. > >> Agreed. If you put them on the RoadMap, I might get to them before you. > > > > Well, this comment of Bob completely mystifies me: > > http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582 > > I believe in that thread there were more issues mentioned. > > Can you transcribe them to the RoadMap once we've got clarification on > the issue from Bob please? OK. I'll ask him to test again after patch-6 is in (or test myself). > > Ahh, and there was another one: the breakage on need_lib_prefix systems. > > I think we did not mark it release-blocking, but I still would like to > > test Pierre's patch extensively and use it if it turns out good: > > otherwise libltdl will be completely useless on e.g. BeOS. > > Okay. Is that a long standing bug, or a regression? Please mark the > RoadMap accordingly :-) Well, both. Apparently dlpreloading has never worked on need_lib_prefix systems, so that is long-standing. Now that libltdl requires working dlpreloading, it fails to work completely, while in 1.5.x it at least worked in some cases. From a user POV, that's a regression, from a Libtool developer POV it's long-standing. ;-) > Just discovered yet another in my patch queue (needs another round of > testing before I post): make installcheck currently always fails in > trees that used 'libtoolize --ltdl' in some modes. (Added to RoadMap). OK. Cheers, Ralf
Re: libtool-2.0 release
Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf! [Is the personal Cc: okay? The list lag is so long that I've gotten into the habit of Cc:ing you back in so you don't have to wait half a day to get this.] > > > > * 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? > > > > It means that LT_WITH_LTDL in configure.ac that mentions neither > > LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all. > > I have a start to a fix for this. > > Well, so is that really a bug? AFAIK the 1.5 docs require you to use > AC_LIB_LTDL, _not_ AC_WITH_LTDL (that exists but isn't even mentioned in > the docs), and AFAICS AC_LIB_LTDL *will* cause libltdl to be built: see > the second old-am-iface.at test, which explicitly does this. The > updated form of AC_LIB_LTDL is LTDL_INIT, not LT_WITH_LTDL. However, > our current CVS HEAD documentation fails to even mention LTDL_INIT. I > wonder whether this is maybe a bug in documentation only? I originally wrote LT_WITH_LTDL as a convenience wrapper for AC_LIB_LTDL in CVS M4, and realised that it was useful enough to almost all clients of libltdl that it should probably belong in the Libtool distribution... There is definitely a documentation bug (added to RoadMap) that it is still undocumented. The real question then is whether LT_WITH_LTDL alone should be equivalent to LTDL_CONVENIENCE plus LTDL_INIT (overridable with LTDL_INSTALLABLE) or whether it should be *in addition* to all that. I'm leaning toward the former, but either way the current situation of being like LTDL_INIT plus --with-ltdl processing is counter-intuitive. I'll post a documentation patch to help us define the semantics clearly, and then fix the code to implement what we decide upon. > > > > * fix potential denial of service with compilers that do not > > > >understand "-c -o". > > > > > > 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 > > > Okay. I'll leave it on the list as is until you determine whether to > > postpone or not. > > The Debian bug is unrelated. I'll still try to finish my pending patch > today and post it: we can still decide then whether it's more risky to > apply it or to postpone it. Excellent! >>> 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') >> I agree that fixing regressions is necessary. I'm not sure that we >> need to delay the release for new features... Can you amend the RoadMap >> to reflect your thinking on this please? > > Sure. Can we agree on adding `-static-libtool-libs'? Rationale: the > semantic change of `-static' effectively caused a regression for users. > The new flag is to amend this. Okay, if you think it will save bug-libtool traffic later. Let me review that patch in its own thread first. > I'll await answer on this and update the TODO list then. Cool, thanks! >>> - 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. >> Agreed. If you put them on the RoadMap, I might get to them before you. > > Well, this comment of Bob completely mystifies me: > http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582 > I believe in that thread there were more issues mentioned. Can you transcribe them to the RoadMap once we've got clarification on the issue from Bob please? > There was one other one, and from memory, I believe it goes like this: > suppose we have a package with libltdl. If the user does > --without-included-ltdl > then I believe `-Ilibltdl' and such paths get still added to includes, > which is wrong. > > I don't remember from memory whether that was for subpackage libltdl, > or for nonrecursive, or for recursive. Sorry. Ick. I guess we'll trip over it during pre-release testing. > Ahh, and there was another one: the breakage on need_lib_prefix systems. > I think we did not mark it release-blocking, but I still would like to > test Pierre's patch extensively and use it if it turns out good: > otherwise libltdl will be completely useless on e.g. BeOS. Okay. Is that a long standing bug, or a regression? Please mark the RoadMap accordingly :-) > We should probably work a bit on feedback documentation. The rate of > users for which the first reply is "please post this and that as well" > is still a bit high. I must admit being not too good at working on > documentation NP. I'll take that one. Just discovered yet another in my patch queue (needs another round of testing before I post): make installcheck currently always fails in t
Re: libtool-2.0 release
On Fri, 3 Feb 2006, Ralf Wildenhues wrote: It means that LT_WITH_LTDL in configure.ac that mentions neither LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all. I have a start to a fix for this. Well, so is that really a bug? AFAIK the 1.5 docs require you to use AC_LIB_LTDL, _not_ AC_WITH_LTDL (that exists but isn't even mentioned in the docs), and AFAICS AC_LIB_LTDL *will* cause libltdl to be built: see the second old-am-iface.at test, which explicitly does this. The updated form of AC_LIB_LTDL is LTDL_INIT, not LT_WITH_LTDL. However, our current CVS HEAD documentation fails to even mention LTDL_INIT. I wonder whether this is maybe a bug in documentation only? I have not checked the latest documentation, but as I mentioned before, the documentation for the legacy libtool configuration macros should be added back to the documentation along with a note to the extent that they are deprecated and are subject to eventual removal. The fact that these older macros still work is vital to the acceptance of libtool 2.0. Well, this comment of Bob completely mystifies me: http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582 I believe in that thread there were more issues mentioned. I am intentionally using GNU sed 3.02. It is possible that the mystery is related to sed versions. There was one other one, and from memory, I believe it goes like this: suppose we have a package with libltdl. If the user does --without-included-ltdl then I believe `-Ilibltdl' and such paths get still added to includes, which is wrong. I don't remember from memory whether that was for subpackage libltdl, or for nonrecursive, or for recursive. Sorry. The problem is when generating the Makefile.inc used for the nonrecursive libltdl build. ACK. I think we can be justifiably proud of the huge improvements we've brought to the new testsuite in the last 18 months. :) I think with about 10-20 times as much test exposure we can have almost well-defined semantics in libtool. In my experience, if something has not been explicitly tested, it is likely to be broken. So the improved test suite reflects actual improvements in libtool 2.0 itself. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool-2.0 release
Hi Gary, * Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET: > Ralf Wildenhues wrote: > > > > - 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 haven't tripped over those yet. Hehe. This turned out to possibly have been - one system with a wrong clock, and - another system (w32) with lower time stamp resolution (moving file _from_ there elsewhere). Very good. I'm moving the regression to wontfix, as we can probably just ignore this unless somebody stumbles over it again. :-) Cheers, Ralf
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
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
Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]
On Thu, 2 Feb 2006, Gary V. Vaughan wrote: 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 I know that Ralf is aware of a few more release-blocking issues than these. One of them is to be able to libtoolize with a libltdl directory using the non-recursive option and end up with a subordinate Makefile.inc which works. Currently the generated Makefile.inc takes some hand-tweaking. 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. I have been re-libtoolizing various projects with libtool 2.0 and have encountered resounding success with MinGW (very good!). Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]
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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
