Re: Shared libraries on AIX
On Sat, 9 May 2009 20:01:18 +0200 Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hi Steve, * Steve Edwards wrote on Sat, May 09, 2009 at 02:11:11PM CEST: [ -brtl ] Should libtool be adding this flag, or is this something I should be manually adding via AM_LDFLAGS? Every other aspect of the shared library build is handled fine by libtool. As Bob already noted, you should be using it at configure time: ./configure LDFLAGS=-Wl,-brtl (or maybe set judiciously inside configure.ac). Quoting doc/notes.txt: * On AIX there are two different styles of shared linking, one in which symbols are bound at link-time and one in which symbols are bound at runtime only, similar to ELF. In case of doubt use `LDFLAGS=-Wl,-brtl' for the latter style. Thanks to both Ralf and Bob. In that case, I will set this in configure.ac. I hadn't realised it was a policy level decision for this flag. Note that the Libtool macros will take some different turns when they see -brtl at configure time. I did notice a few checks in the generated configure script when I took a quick look! Thanks again Steve -- -- -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Shared libraries on AIX
Hi, I ran into a slight difficulty with shared libraries on IBM AIX systems using libtool 2.2.6 (I'm not even sure if this is really where I should be asking questions about this) If I have a main Fortran routine containing a common block and call a Fortran subroutine in a shared library also referencing this common block, the values in the common block were not being inherited in the subroutine (Fortran common blocks across shared libraries may not be ideal, but I was testing something out thinking about libltdl). I did however find that manually adding -brtl to LDFLAGS allowed this to work. The documentation I had available stated that -brtl is used to determine which algorithm will be used to find libraries, however there was more info on the ibm site which cleared up some confusion for me. Should libtool be adding this flag, or is this something I should be manually adding via AM_LDFLAGS? Every other aspect of the shared library build is handled fine by libtool. If anyone has any suggestions on this I would be grateful to hear them. A secondary problem (while trying to do something particularly non-standard I suspect) was to access Fortran common blocks from within shared library C routines, but that does not appear to be anything to do with libtool. If anyone is interested I have available a cut down test case to duplicate what happens. Steve -- -- -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Fortran DLLs on mingw32
On Thu, 8 Jan 2009 19:25:03 +0100 Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Steve, Hello and thanks for the reply. * Steve Edwards wrote on Thu, Jan 08, 2009 at 05:51:27PM CET: This is just a request to find out if anyone out there has tried using libtool to build Fortran DLLs under mingw32? First question I'd ask: which gfortran version, and can it (or a newer available version) build a shared libgfortran? That should avoid the problems you're having, I hope. We are currently using the most up to date version available from the mingw downloads: 4.3.0 (20080305) alpha which I believe is provided as one of the Technology Demonstrator packages. We do have gcc-4.3.2 as source but mingw is one platform I have never tried bootstrapping gcc on (yet...) Looking at the FSF GCC tree, it doesn't seem like they're building shared libgfortran shared on w32 yet (but I don't know whether MinGW/MSYS has modified GCC in this regard). Guess it's worth asking about this (on either, not both) upstream. A fix could be as easy as adding -no-undefined to libgfortran/Makefile.am and AC_LIBTOOL_WIN32_DLL to libgfortran/configure.ac. I may try a gcc bootstrap myself first though - if I have no success, I'll try the gfortran list later (as of the two, that is the one I'm on). The problem was when a Fortran program in the library package tries to link against the created DLL (it was actually a test case wrapper) It fails with a number of multiple definition errors: __gfortran_set_options __gfortran_transfer_character __gfortran_st_write_done __gfortran_st_write It appears that the DLL creation has pulled in symbols from the libgfortran compiler runtime? Am I correct in assuming that this is due to the gfortran runtime not being available in DLL form? Probably. A quick workaround would appear to be to use either one of '-export-symbols FILE' or '-export-symbols-regex REGEX' with an argument suitable of listing only the symbols from your library. Untested. I expect we will wait now until the FSF gcc tree builds DLLs on mingw by default, but we will give the '-export-symbols-regexp REGEX' option a try to see how it goes. For the moment we are building static libraries for program linking and using a custom rule to build the shared version. Hope that helps. It has been a great help - thanks very much. Steve -- -- Yow! of the hour: Exceptions always outnumber rules.7 -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Fortran DLLs on mingw32
Hi, This is just a request to find out if anyone out there has tried using libtool to build Fortran DLLs under mingw32? We had some Fortran code built as a shared library that could be loaded into Matlab quite happily on Linux systems and also used as a conventional library linked against by several programs. We're now looking to see if we could make that library available on mingw32 We are using automake 1.10.1, autoconf 2.63 and libtool 2.2.6 After a bit of digging around I thought that this would be possible by adding win32-dll to LT_INIT and adding -no-undefined to libmattest_la_LDFLAGS in the relevant Makefile.am as mentioned in the info. As it is Fortran we can't use the __declspec(dllexport) and __declspec (dllimport) as mentioned in the docs, but from my limited understanding, if this is never used, libtool exports all symbols? This appeared to produce a DLL. The problem was when a Fortran program in the library package tries to link against the created DLL (it was actually a test case wrapper) It fails with a number of multiple definition errors: __gfortran_set_options __gfortran_transfer_character __gfortran_st_write_done __gfortran_st_write It appears that the DLL creation has pulled in symbols from the libgfortran compiler runtime? Am I correct in assuming that this is due to the gfortran runtime not being available in DLL form? Provided it is stand alone, this DLL does appear to work in Matlab, but we cannot link Fortran programs with it. If we have a .so for Matlab that depends on other libraries, we don't appear to be able to create those libraries as DLLs (as we would create .so's on a UNIX system) due to these duplicate symbols that appear in each DLL. This does not appear to matter with PE however (PE is always PIC?) It is very likely that I've misunderstood the whole DLL approach here - would it make more sense to create static libraries separately for program linking and manually create a DLL for Matlab loading? If anyone has any suggestions or pointers, I'd greatly appreciate hearing them. Steve -- -- -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLLs on mingw
I fixed the problem by adding an explicit -no-undefined to the libtool link command - is this considered to be the correct fix or am I missing something obvious? This is correct. If you use AM_PROG_LIBTOOL or AC_PROG_LIBTOOL in your configure.ac script, add AC_LIBTOOL_WIN32_DLL just before. This way is deprecated If you use LT_INIT, pass win32-dll to it In both case, you have to pass -no-undefined to libtool (during linking). See http://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT Many thanks for that - I've updated the build system accordingly! Everything working fine now. (I hadn't even realised that AC_PROG_LIBTOOL was deprecated now!) Steve -- -- Yow! of the hour: Progress is made on alternative Fridays. -- ___ http://lists.gnu.org/mailman/listinfo/libtool
multiarch procedure
Hi, I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Most of the systems I'm targeting are Fedora which expect 64bit libraries in /usr/local/lib64 etc. and use /usr/local/lib only for 32bit. The compilers I have installed on the x86_64 test machine all build 64bit libraries by default (which is what I want) but $(libdir) defaults to /usr/local/lib Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little reluctant to have to tell everyone building the libraries that they may (or may not) have to use this switch since I really was hoping to keep the configure stage as automatic as possible. I've done some googling on the subject (with little or nothing concrete to show for it) and it appears that Fedora libtool was patched for multiarch support - although I'm currently uncertain whether this is still true. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of unless you know what this is you don't need it) but I certainly can't find anything on my home system (libtool 2.2.4) Any suggestions for a 'correct' approach will be gratefully received! (Please CC me in any replies as I am not subscribed to libtool on this email account) Steve -- ___ http://lists.gnu.org/mailman/listinfo/libtool
hppa2.0-hp-hpux10.20 mixed Fortran and C
Hi, I'm using libtool version 1.5.22 within a GNU autotools framework. I've just been trying to build a library on hppa2.0-hp-hpux10.20 containing source files in both Fortran and C and using the HP /opt/ansic/bin/cc and /opt/fortran/bin/fort77 compilers The configure stage works fine: CC=/opt/ansic/bin/cc F77=fort77 ./configure However, when building, the Fortran builds correctly but the C routines all fail as follows (sorry - the lines may autowrap): source='ul_beeper.c' object='ul_beeper.lo' libtool=yes \ DEPDIR=.deps depmode=hp /usr/bin/posix/sh ../depcomp \ /usr/bin/posix/sh ../libtool --tag=CC --mode=compile /opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z 2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c mkdir .libs /opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z -c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo +Z -DPIC -o .libs/ul_beeper.o /opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z -c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo -o ul_beeper.o /dev/null 21 fort77 -I.. -I./../include -I.. -DWORDS_BIGENDIAN +O2 +U77 +Z -C 2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c make[2]: *** [ul_beeper.lo] Error 1 It creates the file ul_beeper.lo and .libs/ul_beeper.o but I cannot understand why the Fortran compiler is being called for the static library build of the C source. Running 'make -k' and then 'make' creates the library .libs/librsggen-3.1.0.sl but the static library fails to build completely. Re-running configure with: CC=/opt/ansic/bin/cc F77=fort77 ./configure --disable-static produces the following build error: source='ul_beeper.c' object='ul_beeper.lo' libtool=yes \ DEPDIR=.deps depmode=hp /usr/bin/posix/sh ../depcomp \ /usr/bin/posix/sh ../libtool --tag=CC --mode=compile /opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z 2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c mkdir .libs /opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z -c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo +Z -DPIC -o .libs/ul_beeper.o fort77 -I.. -I./../include -I.. -DWORDS_BIGENDIAN +O2 +U77 +Z -C 2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c make: *** [ul_beeper.lo] Error 1 which still looks incorrect. It appears to still build shared library object code (+Z -DPIC) but still fails static library code. Running 'make' again then continues to try and build the next routine. Has anyone else come across anything similar to this? If anyone has any hints on this I'd be very grateful! Steve ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hppa2.0-hp-hpux10.20 mixed Fortran and C
Hello Ralf,
On Wed, 2006-08-23 at 14:04 +0200, Ralf Wildenhues wrote:
Hello Steve,
* Steve Edwards wrote on Wed, Aug 23, 2006 at 01:54:56PM CEST:
The configure stage works fine:
CC=/opt/ansic/bin/cc F77=fort77 ./configure
Please use
./configure CC=/opt/ansic/bin/cc F77=fort77
instead, for consistency.
Right you are. I'll update my notes on this - I've been using the other
invocation for so long now!
However, when building, the Fortran builds correctly but the C routines
all fail as follows (sorry - the lines may autowrap):
source='ul_beeper.c' object='ul_beeper.lo' libtool=yes \
DEPDIR=.deps depmode=hp /usr/bin/posix/sh ../depcomp \
/usr/bin/posix/sh ../libtool --tag=CC --mode=compile /opt/ansic/bin/cc -Ae
-DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z
2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c
mkdir .libs
/opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include
-I.. +Z -c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo +Z -DPIC -o
.libs/ul_beeper.o
/opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include
-I.. +Z -c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo -o ul_beeper.o /dev/null
21
fort77 -I.. -I./../include -I.. -DWORDS_BIGENDIAN +O2 +U77 +Z -C
2xlf.ul_beeper.errors -c -o ul_beeper.lo ul_beeper.c
make[2]: *** [ul_beeper.lo] Error 1
It creates the file ul_beeper.lo and .libs/ul_beeper.o but I cannot
understand why the Fortran compiler is being called for the static
library build of the C source.
This looks like there are some manual overrides in the Makefile.am file.
Could you show a small example exposing this, or show the respective
parts of the Makefile.am? Especially I don't see at all where the
autotools should cause a file like xlf.ul_beeper.errors to be used.
Sorry about that - you are quite correct there are indeed some manual
overrides. I should have added those to the first post. First of all, at
configure time the user can specify EXTRA_FLAGS which are appended to
the compiler flags (see below). The other change is Fortran specific
which (dependant upong platform and compiler) attempts to work out a
method for pre-processing Fortran source. If no flag is know to the
configure script it uses an automake conditional to generate
pre-processed Fortran:
if PPHASH
.f.o:
$(FTNPP) $(FTNPPFLAGS) @DEFINES@ $(AM_CPPFLAGS) `test -f '$' || echo
'$(srcdir)/'`$ $(*F).F $(F77COMPILE) -c -o $@ $(*F).F
endif
If a flag is known it sets FPPFLAGS, but this has to be set for the
compile stage only and not the link stage - g77 uses -xf77-cpp-input and
fails if you leave this in the command line at link time as then it
tries to pre-process the object code.
So the Makefile.am overrides look like:
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) @EXTRA_FLAGS@
LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS) @EXTRA_FLAGS@
F77COMPILE=$(F77) $(AM_FFLAGS) $(FFLAGS) @FPPFLAGS@ @EXTRA_FLAGS@
LTF77COMPILE = $(LIBTOOL) --mode=compile $(F77) $(AM_FFLAGS) $(FFLAGS) \
@FPPFLAGS@ @EXTRA_FLAGS@
Secondly the xlf.ul_beeper.errors file is something set on the FFLAGS
and CFLAGS variables in the configure.am - without the stderr
redirection I get this:
source='ul_beeper.c' object='ul_beeper.lo' libtool=yes \
DEPDIR=.deps depmode=hp /usr/bin/posix/sh ../depcomp \
/usr/bin/posix/sh ../libtool --tag=CC --mode=compile /opt/ansic/bin/cc -Ae
-DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z -c -o
ul_beeper.lo ul_beeper.c
mkdir .libs
/opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z
-c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo +Z -DPIC -o .libs/ul_beeper.o
/opt/ansic/bin/cc -Ae -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./../include -I.. +Z
-c ul_beeper.c -Wp,-M.deps/ul_beeper.TPlo -o ul_beeper.o /dev/null 21
fort77 -I.. -I./../include -I.. -DWORDS_BIGENDIAN +O2 +U77 +Z -C -c -o
ul_beeper.lo ul_beeper.c
ul_beeper.c:
(Bundled) cc: ul_beeper.c, line 82: error 1705: Function prototypes are an
ANSI feature.
(Bundled) cc: ul_beeper.c, line 82: error 1505: Function may not return a
function or an array.
(Bundled) cc: ul_beeper.c, line 82: error 1573: Type of F77_FUNC_ is
undefined due to an illegal declaration.
fort77: Errors detected
make: *** [ul_beeper.lo] Error 1
I've been through the C source and it compiles fine with gcc on every
platform I can access, xlc on RS/6000, Sun Workshop cc compiler. The
F77_FUNC_ is a definition set for the Fortran name mangling convention.
In case you're wondering, the line it complains about merely says:
void UL_BEEPER_F77(void) {
I still don't quite see why it's trying to build the C with fort77
especially as it appears to be building the static and shared object
version correctly on the previous two lines(?)
Commenting out
Re: hppa2.0-hp-hpux10.20 mixed Fortran and C
On Wed, 2006-08-23 at 15:29 +0200, Ralf Wildenhues wrote: Automake has some support for preprocessed Fortran 77. Could you try whether that is sufficient for you, and if not, please describe what is missing (I am trying to whip up Fortran support a bit at the moment...)? Please see the Automake documentation for details. I'll have a look through and see what is available. I'm glad Fortran support is still being pushed ;-) One point that does spring to mind is the IBM xlf/xlf90 compiler that rejects -DDEFINE. You have to pass the -D option via -WF,-DDEFINE with that compiler as far as I understand it. The -D is used for compiling lines of fixed source form Fortran code that have a D in column 1. The conditional appeared to be an easy way of generating pre-processed source bypassing the compiler. What do you need the @EXTRA_FLAGS@ for? Legacy. Personally I'd rather just remove it. Maybe if I can find a large enough stick... If no flag is know to the configure script it uses an automake conditional to generate pre-processed Fortran: if PPHASH .f.o: $(FTNPP) $(FTNPPFLAGS) @DEFINES@ $(AM_CPPFLAGS) `test -f '$' || echo '$(srcdir)/'`$ $(*F).F $(F77COMPILE) -c -o $@ $(*F).F endif Besides the fact that I think Automake does not cope well with conditional overrides of inference rules, I believe you need to override the rule for `.f.lo' as well, for files handles by libtool. I think this is the cause for the error you see (untested). Well, I assembled a stripped down library and of course that worked fine! As soon as I added the pre-processing conditional though it was back to the same problem - you are quite correct, it is indeed the pre-processing section. Manually adding .f.lo did correct it with warnings regarding overriding commands for target `.f.o' If the automake conditional was re-enabled with an entry for .f.lo: then automake very kindly commented out the entries .f.o: $(F77COMPILE) -c -o $@ $ .f.lo: $(LTF77COMPILE) -c -o $@ $ that would other wise have been present and *that* caused the error to resurface. Uncommenting these lines resulted in the warnings regarding overriding commands again but this time it built perfectly fine. Completely hidden on most platforms but crept out of the woodwork to bite me on hppa2.0. If a flag is known it sets FPPFLAGS, but this has to be set for the compile stage only and not the link stage - g77 uses -xf77-cpp-input and fails if you leave this in the command line at link time as then it tries to pre-process the object code. See above, that should be a non-issue if you use file names ending in .F, given that Automake does the preprocessing logic correctly then. Automake will use PPF77COMPILE = $(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS) for compilation. If that is a problem with colliding *CPPFLAGS for C/C++ files compiled from the same Makefile.am, you could just compile them in a different directory as a workaround. PPF77COMPILE I didn't know. Thanks. Thanks for your help and hints on this problem - it looks like the correct fix would be to switch to using .F and let automake deal with the pre-processing. Steve ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 on hppa2.0-hp-hpux10.20
On 2003.08.18 06:52 Schleicher Ralph (LLI) wrote: Steve Edwards writes: (Warning) At least one PA 2.0 object file (conftest.o) was detected. The linked output may not run on a PA 1.x system. Add LDOPTS='+vnocompatwarnings +s' export LDOPTS to your .profile file. Thanks for that. It's (almost) worked. This prevents the linker warning from appearing, however, libtool still insists that the +Z flags for PIC does not work with the native hp f77. The native f77 lists on standard error the names of each source file and procedure as they are encountered. libtool checks that there is _nothing_ on stderr. From the configure script: # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings if test ! -s conftest.err; then lt_prog_compiler_pic_works_F77=yes fi When conftest.f is compiled however, the native compiler writes to stderr: conftest.f: t: where 't' is the name of the conftest subroutine. This is similar behaviour to the IBM AIX xlf/xlf90 compiler and the Sun sparc compiler f77, all of which write to stderr to say that everything compiled okay (?!). So in all of the cases I've seen so far, the Fortran compiler checks for PIC flags always return 'no' unless you are using GCC (IBMs xlf/xlf90 on AIX systems don't count as all code on rs6000 is PIC anyway). Have I missed something very obvious on all of these sytems? Steve ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.5 on hppa2.0-hp-hpux10.20
Just for the information of the libtool maintainers I thought you might be interested in a few 'features' of the hpux system. I have just been trying libtool 1.5 on this architecture using the native hp tools. I am using the HP ANSI C compiler and HP FORTRAN/9000. When trying to build shared libraries, libtool checks that the PIC flag (+Z) actually works. The check with the C compiler fails. The comment in the configure script states that: # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings Unfortunately, on this platform, there is also a warning message generated by cc saying: (Warning) At least one PA 2.0 object file (conftest.o) was detected. The linked output may not run on a PA 1.x system. which is completely unrelated to the +Z but causes libtool to report a failure anyway. The fortran compiler does not appear to generate this warning but also reports that the PIC flag (+Z) does not work. The fortran compiler sends the following message to stderr when checking +Z conftest.f: t: and as the conftest.err file is not zero sized, libtool again reports a failure when all the compiler is doing is reporting compilation progress. The same 'feature' of the HP compiler causes libtool to also report that fort77 does not support -c -o file.o which it certainly does. Everything works fine though if you switch to using gcc... -- -- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
arg list too long error
I'm trying to port an existing library to use libtool (version 1.4.3) and have run into a problem with long argument lists on an rs6000-ibm-aix4.3.2.0 system. The limiatation is with the AIX linker. The original method used to build the library, built individual sections and progressively added the object files to a .a file with ar -ru libfoobar.a subdir/*.o for all required subdirectories. This was then converted to a shared object library with: ld -bE:shrsubs.exp -bI:shrsubs.imp -bM:SRE -bnoentry -o \ $(LIBRARY).so.$(VERSION) $(LIBRARY)-$(VERSION).a @FLIBS@ -lc All fine for an rs6000. The current situation is to build noinst_LTLIBS convenience libraries in each subdirectory. Building on an ix86 system, the shared library is created by libtool from the individual .libs/libfoobar1.al in the subdirectories, and the static library is created by unpacking the individual .libs/libfoobar1.al and using ar -cru on _all_ of the individual object files. This is fine on the ix86. The rs6000 unpacks the individual library archives for _both_ static and shared and immediately hits the limit for the argument list for ld. I suppose my first question is why can I not link all the .libs/libfoobar1.al on the rs6000 _without_ unpacking the library archives, and my second is has anyone else run across this before and come up with a solution? Steve -- -- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
