RE: MSYS+MSVC for libtool branch-2-0, take 7
Ralf Wildenhues wrote: Thanks a lot for the overview. No problem. I have a couple of comments for stuff you have not split out yet, see below (and a couple of issues I have not looked at yet; but I did not want to wait even longer with this mail). Regarding splitting things out, How small chunks should I make? I mean, the lib as archiver seems like a unit. As is the case with dumpbin as name lister. The rest is also a unit in some sence as it's all to do with support for MSVC, perhaps a natural boundary is C vs C++. Should I also split C support into basic support and fixes for various elaborate test cases? Do you have any guidance on how I generate such a patch series using cvs, and how I keep it up to date? Should I just split it out bit by bit and do it the slow way, one patch at a time? I could manage when it was a handfull of unrelated oneliners, but this is more intricate... tagdemo-*.test -- Apart from a bunch of shared lib description variables, I have also made a dirty change. Without it C++ fails miserably for MSVC. cl.exe only detects .cpp and .cxx files as C++ source files. If you have source files e.g. foo.cc and bar.cc, you have to say: cl -Tp foo.cc -Tp bar.cc or cl -Tpfoo.cc -Tpbar.cc and so on for each file that is a C++ source file. Otherwise, cl simply forwards the file to the linker... So, I made this dirty change: ac_ext=cpp instead of ac_ext=cc (the same is true for C source files, which has to be named .c, or you have to use the -Tc option. But who does not name C source files .c?) Hmm, I thought there were a non-position dependent option for cl.exe to make it compile C code.. *time passes* this version: | Version 13.10.3077 for 80x86 states: | /Tcsource file compile file as .c | /Tpsource file compile file as .cpp | /TC compile all files as .c | /TP compile all files as .cpp so you should be fine with CC='cl -TC'. Does that work with your version as well? (Sorry for not mentioning -TC and -TP, but I ruled them out as useless, maybe that was hasty, but I can't think of a way to use them) I have them, but CC='cl -TP' is no good. The -TP switch has the bad effect of really compiling *all* files as .cpp, which is not what you want. If you for example do cl -TP foo.cc wsock32.lib the dang tools will barf on the library not being C++. So, the only way to use -TP and -TC is to always compile first (with -c switch) and then link. I think libtool always does it this way so that may not be a problem? But you still can't add -TP to $CC as $CC is also used to link. So you have to add -TP to CPPFLAGS, but I didn't find a corresponding variable for C++, so you want different CPPFLAGS for C and C++. Is there such a beast as CXXCPPFLAGS or whatever it may be called? Can tags be of use here? (I'm pretty ignorant when it comes to tag variables) Still, we should think of changing ac_ext so it works out of the box. Doesn't this need a patch against Autoconf? One reason to change ac_ext to .cpp is that the sources in the tests use .cpp, so that is what you should test for. Perhaps not a great reason, and I'm biased as I'm a lazy person... With the above dirty change, it works. Also, since MSVC uses @ and ? in C++ symbols (it also uses @ for __fastcall C symbols for that matter) I'm unsure of how ltdlopen (and preopen) will work... Later. * Support for NM=dumpbin -symbols as the name lister. Nice! Maybe not so great though. I recently downloaded the free C++ 2003 Toolkit and the latest Platform SDK and dumpbin was not included. I wonder if support for this tool has been dropped? Does anybody know? I did a search on MSDN and there is no information provided in the Visual Studio 2003 docs, when I look in the place dumpbin was documented in previous MSVCs. Dropping support for dumpbin is not mentioned in changes so perhaps the docs has just moved. I don't think so however, it looks like dumpbin is a goner. And I can't find a tool that can fill the gap. Crap! Help! Maybe I should just give up and say that some tools from binutils are required. No big deal really. The lib as archiver patch is still needed though, as this seems like the easiest way to get at all symbols from a library with so many objects that the max command line length is exceeded (pdemo.test), as the Microsoft linker does not seem to support reloadable objects. You *could* extract symbols from one object at a time and merge the outcome, but I think that would be a much bigger change. Testsuite = Here's the output from make check, when configured with: configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link AR=lib STRIP=: NM=dumpbin -symbols F77=: This is my environment: Could you be bothered to run the new test suite as well for this environment? make check TESTS= (adding TESTSUITE_FLAGS=-v or also -d comes in handy at times, but the autotest test suite saves a lot of
Re: MSYS+MSVC for libtool branch-2-0, take 7
Hi Peter, * Peter Ekberg wrote on Tue, Aug 09, 2005 at 10:18:03AM CEST: Ralf Wildenhues wrote: Thanks a lot for the overview. No problem. I have a couple of comments for stuff you have not split out yet, see below (and a couple of issues I have not looked at yet; but I did not want to wait even longer with this mail). Regarding splitting things out, How small chunks should I make? Ideally: small enough so they are still self-contained, plus easy to review. Realistically, time is finite, so don't waste too much on this. I mean, the lib as archiver seems like a unit. As is the case with dumpbin as name lister. The rest is also a unit in some sence as it's all to do with support for MSVC, perhaps a natural boundary is C vs C++. Should I also split C support into basic support and fixes for various elaborate test cases? Naa, do three patches: lib as archiver, dumpbin as name lister, and MSVC support. Maybe split out the file_magic_glob part too as it's easy to review. I'm still very unsure about the lib as archiver patch, esp as to the naming of the new variables. Maybe $AR $AR_FLAGS $AR_OFLAG$libname $objects is better, with $AR_OFLAG empty on *nix, and $AR_FLAGS empty for lib? Maybe such a style is easier to copy for Automake? (Better keep this discussion to the respective thread, though.) Do you have any guidance on how I generate such a patch series using cvs, and how I keep it up to date? Should I just split it out bit by bit and do it the slow way, one patch at a time? I could manage when it was a handfull of unrelated oneliners, but this is more intricate... I've always wanted to look at quilt.. but what I actually do is just a bunch of diff output that gets applied and reverse applied. If you want to know the ugly way: When splitting up a large diff, I just go through it linearly and move the chunks as I go along. No, this is far from optimal or nice. Once you have it separated, things should work more or less straightforward. I believe your patch and Keith's proposed patch for -sobase interact (i.e., -sobase support would have to be forward ported into your patch.) cl -Tp foo.cc -Tp bar.cc *snip* Hmm, I thought there were a non-position dependent option for cl.exe to so you should be fine with CC='cl -TC'. Does that work with your version as well? (Sorry for not mentioning -TC and -TP, but I ruled them out as useless, maybe that was hasty, but I can't think of a way to use them) I have them, but CC='cl -TP' is no good. The -TP switch has the bad effect of really compiling *all* files as .cpp, which is not what you want. If you for example do cl -TP foo.cc wsock32.lib the dang tools will barf on the library not being C++. Ouch. So, the only way to use -TP and -TC is to always compile first (with -c switch) and then link. I think libtool always does it this way so that may not be a problem? Yes, libtool requires separated modes for compilation and linking. But you still can't add -TP to $CC as $CC is also used to link. So you have to add -TP to CPPFLAGS, but I didn't find a corresponding variable for C++, so you want different CPPFLAGS for C and C++. Is there such a beast as CXXCPPFLAGS or whatever it may be called? Can tags be of use here? (I'm pretty ignorant when it comes to tag variables) We could just weed out -TP and -TC in func_mode_link. Then you can put them in CFLAGS/CXXFLAGS, or even CC/CXX, which I believe is a good thing. CPPFLAGS would have been more correct, but it's shared between C and C++. Still, we should think of changing ac_ext so it works out of the box. Doesn't this need a patch against Autoconf? One reason to change ac_ext to .cpp is that the sources in the tests use .cpp, so that is what you should test for. Perhaps not a great reason, and I'm biased as I'm a lazy person... Well, the question is not how to make it easier for the testsuite to work but for the users in the end. They are not going to rename their files too *.cpp, so we'll have to cope anyway. Also, since MSVC uses @ and ? in C++ symbols (it also uses @ for __fastcall C symbols for that matter) I'm unsure of how ltdlopen (and preopen) will work... Later. Let's just see about this when we something breaks. * Support for NM=dumpbin -symbols as the name lister. Nice! Maybe not so great though. I recently downloaded the free C++ 2003 Toolkit and the latest Platform SDK and dumpbin was not included. I wonder if support for this tool has been dropped? Does anybody know? I did a search on MSDN and there is no information provided in the Visual Studio 2003 docs, when I look in the place dumpbin was documented in previous MSVCs. Dropping support for dumpbin is not mentioned in changes so perhaps the docs has just moved. I don't think so however, it looks like dumpbin is a goner. And I can't find a tool that can fill the gap. Crap! Help! Hmm. Online MSDN docs don't seem to
Re: MSYS+MSVC for libtool branch-2-0, take 7
* Peter Ekberg wrote on Tue, Aug 09, 2005 at 02:40:36PM CEST: Ralf Wildenhues wrote: I believe your patch and Keith's proposed patch for -sobase interact (i.e., -sobase support would have to be forward ported into your patch.) Seems like a simple s/libname/sobase_name/ but someone has to remember to do it... Kind of like that. Plus maybe run a test. The lib as archiver patch is still needed though, as this seems like the easiest way to get at all symbols from a library with so many objects that the max command line length is exceeded (pdemo.test), as the Microsoft linker does not seem to support reloadable objects. You *could* extract symbols from one object at a time and merge the outcome, but I think that would be a much bigger change. I'm still not convinced that we don't end up having more trouble with paths encoded into the archive. But since lib does that anyway, I guess we might just have to care for all bad cases (see that we don't encode paths, but expect encoded paths in other libs). I must admit I haven't checked your patch closely w.r.t this yet. In the patch, the archive built to get the symbols is not used for anything but getting the symbols. But two features in lib are used that are not supported by ar. Namely that lib can take a command file with inputs (@cmdfile notation) so that the command line length is short, and the fact that the path is indeed stored in the archive, so that object file renaming is not needed for this temporary symbol extracting archive. Can we get in the position that both might be used (lib in older, already installed libs, ar for a newer package the user is about to link)? I believe not, but need to check so. So, for this, it is not really needed to have AR=lib. It is perhaps cleaner to look up lib (or link -lib) and use that without looking at $AR at all, since ar does not have the required functionality. This is precisely what kind of bugs me. We don't want to prevent use of a GNU tool here. When doing the actual linking, a command file is again used, so it's similar to the linker script approach taken with gnu ld. (except that the linker script isn't used with gnu ld when the command line length is overrun in the extract symbol step, in that case the reloadable object file is used for both symbol extraction and actual link) OK. Cheers, Ralf
RE: MSYS+MSVC for libtool branch-2-0, take 7
Ralf Wildenhues wrote: * Peter Ekberg wrote on Tue, Aug 09, 2005 at 10:18:03AM CEST: Ralf Wildenhues wrote: Thanks a lot for the overview. No problem. I have a couple of comments for stuff you have not split out yet, see below (and a couple of issues I have not looked at yet; but I did not want to wait even longer with this mail). Regarding splitting things out, How small chunks should I make? Ideally: small enough so they are still self-contained, plus easy to review. Realistically, time is finite, so don't waste too much on this. Great. I mean, the lib as archiver seems like a unit. As is the case with dumpbin as name lister. The rest is also a unit in some sence as it's all to do with support for MSVC, perhaps a natural boundary is C vs C++. Should I also split C support into basic support and fixes for various elaborate test cases? Naa, do three patches: lib as archiver, dumpbin as name lister, and MSVC support. Maybe split out the file_magic_glob part too as it's easy to review. Ok. I'm still very unsure about the lib as archiver patch, esp as to the naming of the new variables. Maybe $AR $AR_FLAGS $AR_OFLAG$libname $objects is better, with $AR_OFLAG empty on *nix, and $AR_FLAGS empty for lib? Maybe such a style is easier to copy for Automake? (Better keep this discussion to the respective thread, though.) Do you have any guidance on how I generate such a patch series using cvs, and how I keep it up to date? Should I just split it out bit by bit and do it the slow way, one patch at a time? I could manage when it was a handfull of unrelated oneliners, but this is more intricate... I've always wanted to look at quilt.. but what I actually do is just a bunch of diff output that gets applied and reverse applied. If you want to know the ugly way: When splitting up a large diff, I just go through it linearly and move the chunks as I go along. No, this is far from optimal or nice. Once you have it separated, things should work more or less straightforward. I believe your patch and Keith's proposed patch for -sobase interact (i.e., -sobase support would have to be forward ported into your patch.) Seems like a simple s/libname/sobase_name/ but someone has to remember to do it... cl -Tp foo.cc -Tp bar.cc *snip* Hmm, I thought there were a non-position dependent option for cl.exe to so you should be fine with CC='cl -TC'. Does that work with your version as well? (Sorry for not mentioning -TC and -TP, but I ruled them out as useless, maybe that was hasty, but I can't think of a way to use them) I have them, but CC='cl -TP' is no good. The -TP switch has the bad effect of really compiling *all* files as .cpp, which is not what you want. If you for example do cl -TP foo.cc wsock32.lib the dang tools will barf on the library not being C++. Ouch. So, the only way to use -TP and -TC is to always compile first (with -c switch) and then link. I think libtool always does it this way so that may not be a problem? Yes, libtool requires separated modes for compilation and linking. Good, good... But you still can't add -TP to $CC as $CC is also used to link. So you have to add -TP to CPPFLAGS, but I didn't find a corresponding variable for C++, so you want different CPPFLAGS for C and C++. Is there such a beast as CXXCPPFLAGS or whatever it may be called? Can tags be of use here? (I'm pretty ignorant when it comes to tag variables) We could just weed out -TP and -TC in func_mode_link. Then you can put them in CFLAGS/CXXFLAGS, or even CC/CXX, which I believe is a good thing. CPPFLAGS would have been more correct, but it's shared between C and C++. This is possible yes, I'll look into it. I need to update the patch anyway, now that all the small stuff have been commited. Still, we should think of changing ac_ext so it works out of the box. Doesn't this need a patch against Autoconf? One reason to change ac_ext to .cpp is that the sources in the tests use .cpp, so that is what you should test for. Perhaps not a great reason, and I'm biased as I'm a lazy person... Well, the question is not how to make it easier for the testsuite to work but for the users in the end. They are not going to rename their files too *.cpp, so we'll have to cope anyway. Yes... Also, since MSVC uses @ and ? in C++ symbols (it also uses @ for __fastcall C symbols for that matter) I'm unsure of how ltdlopen (and preopen) will work... Later. Let's just see about this when we something breaks. * Support for NM=dumpbin -symbols as the name lister. Nice! Maybe not so great though. I recently downloaded the free C++ 2003 Toolkit and the latest Platform SDK and dumpbin was not included. I wonder if support for this tool has been dropped? Does anybody know? I did a search on MSDN and there is no
RE: libtool 2-0-lib-as-archiver.patch
[Changing thread] Ralf Wildenhues wrote: I'm still very unsure about the lib as archiver patch, esp as to the naming of the new variables. Maybe $AR $AR_FLAGS $AR_OFLAG$libname $objects is better, with $AR_OFLAG empty on *nix, and $AR_FLAGS empty for lib? Maybe such a style is easier to copy for Automake? (Better keep this discussion to the respective thread, though.) Hey, that's a neat idea! What would you like the names to be? Suggestion: $AR $AR_FLAGS $AR_OFLAGS$libname $objects $AR $AR_TFLAGS $libname $AR $AR_XFLAGS $AR_EFLAGS$libname [$object] With these values for ar and lib respectively: ARarlib AR_FLAGS cru AR_OFLAGS -OUT: AR_TFLAGS t -LIST AR_XFLAGS x AR_EFLAGS -EXTRACT: Throw in -NOLOGO in the lib variants if you like. And it is of course required to keep track of if the whole archive can be extracted in one go, or if you have to loop over the content and extract one file at a time. Then there's the issue with Automake using ARFLAGS, not AR_FLAGS... Cheers, Peter
RE: MSYS+MSVC for libtool branch-2-0, take 7
Ralf Wildenhues wrote: In the patch, the archive built to get the symbols is not used for anything but getting the symbols. But two features in lib are used that are not supported by ar. Namely that lib can take a command file with inputs (@cmdfile notation) so that the command line length is short, and the fact that the path is indeed stored in the archive, so that object file renaming is not needed for this temporary symbol extracting archive. Can we get in the position that both might be used (lib in older, already installed libs, ar for a newer package the user is about to link)? I believe not, but need to check so. So, for this, it is not really needed to have AR=lib. It is perhaps cleaner to look up lib (or link -lib) and use that without looking at $AR at all, since ar does not have the required functionality. This is precisely what kind of bugs me. We don't want to prevent use of a GNU tool here. I don't follow you here. Why is it required that you can use a GNU tool? When you are using MSVC, you are using the Microsoft Linker, so it's not like a new dependency is added. lib is just a synonym for link -lib. So two features of the Microsoft linker (command files and paths being stored in archives) are used to overcome the lack of another feature (reloadable object files). Yes, I know that some of the tests in the patch test for MSVC (or rather, not gcc), when it should be tests for features of the specific tool used, one of the reasons I have not asked for commit yet... Any suggestion on how to clean that up? When doing the actual linking, a command file is again used, so it's similar to the linker script approach taken with gnu ld. (except that the linker script isn't used with gnu ld when the command line length is overrun in the extract symbol step, in that case the reloadable object file is used for both symbol extraction and actual link) OK. Cheers, Peter
Re: deplibs.test broken.
Hi Kurt, Sorry for the late reply. I overlooked your mail the first time. (Feel free to send reminders if answers take time.) * Kurt Roeckx wrote on Sun, Jul 31, 2005 at 02:06:22PM CEST: I'm having a few problem with the deplibs.test. It's broken for several reasons: - It's linking a shared lib against a static lib. This is not portable, and we even give a warning about this. Yes. It should only be run when deplibs_check_method=pass_all. Unfortunately, that is set wrongly in some cases (e.g., linux/x86_64). - The shared lib is not using any symbols from the static lib. - The test program is linked against the shared lib and using symbols from the static lib. Yep. The only reason the test is succesful is that the shared lib isn't using any symbols from the static lib. If it were using symbols from the static lib, the shared lib would have (tried) including whatever is needed to have them, and then linking the shared lib would have failed on some platforms. Yep. I believe the idea was that on the platforms without pass_all, the idea was not to link against the static lib, but to record the dependency in the .la file, so that it would be picked up by later program links (and libs which link against it). Obviously the -no-undefined flag then hurts. To tell you the truth, I don't even know whether that works at all. Most likely it doesn't. Using symbols from a library you're not linking to, and is only pulled in by the dependencies really isn't what you want to do either. Well, some people have wished for this. Regard the .la file as portable record of dependencies. No, I don't like this much either. I have no idea what the intention of this test really is that isn't covered by the other test, so I don't have a suggestion on how to fix it. Did this help? BTW, will you be maintaining the Debian Libtool package? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi Keith, others,
Sorry for the response latency. This is a status update for the -sobase
patch: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html.
* Keith Packard wrote on Mon, Jul 11, 2005 at 09:55:47PM CEST:
On Mon, 2005-07-11 at 13:58 +0200, Ralf Wildenhues wrote:
Re-reading this thread, I would be inclined to accept a patch which
implements your original proposal, given that a way can be found how it
degrades gracefully on the different/not-so-flexible shared library
systems mentioned. That is, unless the other maintainers oppose.
Ok, I've created a '-sobase' option in link mode and tested it on
GNU/Linux. It changes the -soname option passed to the linker so that
instead of using ${libname} for the first part of the soname, it uses
the -sobase parameter. It also includes this generated name as one of
the library_names so that when the library is installed, a symlink to
the soname is made.
Hmm. I've started a test suite test to go along with this, so that we
can actually make sure this works as expected, and also do not
gratuitously break installed .la files and linking against them.
I am a little stuck, however. Maybe someone else can provide input
(be sure to read all the way to the AIX case, however):
Your patch changes library_names in the .la file to also include a name
for the different sobase. You don't, however, add the unversioned name,
thus the unversioned link also is not generated. Isn't this what you
wanted instead? (see also in the test below)
Furthermore, libtool expects the last name in library_names to be the
unversioned name, i.e., the one to link against. The deplib search code
needs adjusting to this (basically the places where library_names is
read from an already-written .la file).
I believe this is the reason that the test currently fails (on linux,
solaris) because it forgets to put the rpath information in
main_static, in case we link against the lib which links against the
-sobase-treated lib: Libtool does not walk its dependency chain.
I haven't completely checked either that libtool implicitly assumes that
the base name of all words in $library_names is the same.
We /might/ be able to limit ourselves to allowing just one of the names
to link to. In any case, the way the result works still needs to be
documented.
Tested on: GNU/Linux/x86_64, Solaris/{gcc,Sun cc}/Solaris ld.
AIX is a completely different matter yet: it can have dynamic archives
ending in .a (with soname ending in .so). Here, your patch breaks
already while creating libtestB.la -- we can't mix the library names
and soname concepts so easily here (As a followup error, the test
seems to bogusly cause removal of the uninstalled .la files -- bad).
I have not tested win32 nor Darwin yet, but expect them to be on a
similar fun level as AIX. (As a minor detail, the test, being
unfinished, is also missing proper initialization for some tools).
Cheers,
Ralf
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.155
diff -u -r1.155 Makefile.am
--- Makefile.am 8 Aug 2005 09:23:57 - 1.155
+++ Makefile.am 9 Aug 2005 07:43:42 -
@@ -301,6 +301,7 @@
tests/stresstest.at \
tests/link-order.at \
tests/convenience.at \
+ tests/sobase.at \
tests/template.at
EXTRA_DIST += $(TESTSUITE) $(TESTSUITE_AT) tests/package.m4
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.15
diff -u -r1.15 testsuite.at
--- tests/testsuite.at 30 Apr 2005 09:30:14 - 1.15
+++ tests/testsuite.at 9 Aug 2005 07:43:42 -
@@ -93,6 +93,8 @@
m4_include([convenience.at])
# link order test
m4_include([link-order.at])
+# sobase test
+m4_include([sobase.at])
# Torturing subdir-objects builds
m4_include([am-subdir.at])
# C++ templates tests
--- /dev/null 2005-08-03 12:45:51.659987528 +0200
+++ tests/sobase.at 2005-08-09 07:39:29.0 +0200
@@ -0,0 +1,90 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2005 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor,
Re: deplibs.test broken.
On Tue, Aug 09, 2005 at 09:41:45AM +0200, Ralf Wildenhues wrote: I have no idea what the intention of this test really is that isn't covered by the other test, so I don't have a suggestion on how to fix it. Did this help? Yes it did. BTW, will you be maintaining the Debian Libtool package? Yes, I will, and that's a problem I came across when trying to make a more recent version of it. I'm just going to disable that test for now. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Tue, 2005-08-09 at 15:13 +0200, Ralf Wildenhues wrote: Hi Keith, others, Sorry for the response latency. This is a status update for the -sobase patch: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html. Thanks for your response and your work on this matter. Your patch changes library_names in the .la file to also include a name for the different sobase. You don't, however, add the unversioned name, thus the unversioned link also is not generated. Isn't this what you wanted instead? (see also in the test below) No, the alternate name is strictly for run-time linking, not compile time library detection. In particular, I'm installing three libraries with the same unversioned name (libXaw.so), so I really *can't* have them install the unversioned name. At compile time, I expect applications to use the 'standard' library name (libXaw6.so, libXaw7.so or libXaw8.so). Furthermore, libtool expects the last name in library_names to be the unversioned name, i.e., the one to link against. The deplib search code needs adjusting to this (basically the places where library_names is read from an already-written .la file). Ah, I never install .la files, so I wouldn't have caught this regression. I suggest that the better fix would be to place the new names earlier in the library_names list. Would that solve the problem here? We /might/ be able to limit ourselves to allowing just one of the names to link to. In any case, the way the result works still needs to be documented. I don't need to permit linking against the alternate name, only against the official name. AIX is a completely different matter yet: it can have dynamic archives ending in .a (with soname ending in .so). Here, your patch breaks already while creating libtestB.la -- we can't mix the library names and soname concepts so easily here (As a followup error, the test seems to bogusly cause removal of the uninstalled .la files -- bad). The question is whether this hack is needed at all on these systems. What I need to do is take an existing application, linked with a specific version of Xaw referenced by '-lXaw' to find the right library. On ELF systems, this means setting the .soname in the library correctly; I don't know what it means for non-ELF systems; it could be as easy as just creating symlinks to the library with the right names. So, what the test should do is build the library with the old name (libXaw.la), link an application and then build the library with the new name (libXaw7.la) and the -sobase option set to libXaw and make sure the application continues to run. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
