Re: [sr #110542] Patch to libtool for solaris 11.4 link-editor which rejects -pthread option

[Robert Boehne]

Wouldn't this patch break Solaris 11.3 and earlier?

On Mon, Sep 20, 2021 at 5:24 AM Stacey Marshall 
wrote:

> URL:
>   
>
>  Summary: Patch to libtool for solaris 11.4 link-editor
> which
> rejects -pthread option
>  Project: GNU Libtool
> Submitted by: staceym
> Submitted on: Mon 20 Sep 2021 10:24:04 AM UTC
> Category: None
> Priority: 5 - Normal
> Severity: 3 - Normal
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email:
>  Open/Closed: Open
>  Discussion Lock: Any
> Operating System: Solaris
>
> ___
>
> Details:
>
> Solaris 11.4 link-editor, ld(1), has been updated to reject options
> '-thread'
> and '-pthread'.
>
> Details from Oracle Bug 22985199 ld(1) should weed out invalid options
> -thread
> and -pthread
>
> > The GNU configuration process has been known to pass the
> > options -thread and -pthread to ld(1), or to the compiler
> > driver which will try and pass them to ld(1).
> >
> > ld(1) uses getopt(3c) processing.  The compilers take the
> > options they know about and pass the others to ld(1).
> >
> > These options, which are specific to gcc, can result in
> > silent errors:
> >
> > % ld -o null.so -G -thread null.o
> > % elfdump -d null.so | fgrep SONAME
> > [0]  SONAME  0x5cread
> >
> > The -t option is peeled off, being a valid ld(1) option,
> > and the rest, '-h read' gets interpreted as an SONAME, which
> > is probably not what the user expected.  If you tried to
> > create an executable, you'd get an error, but it's not
> > immediately obvious where the -h came from:
> >
> > % ld -o main -thread null.o
> > ld: fatal: option '-h read' is incompatible with building \\
> > a dynamic executable
> >
> > With -pthread we get the same result when building a shared
> > object or an executable:
> >
> > % ld -o null.so -G -pthread null.o
> > % elfdump -d null.so | fgrep AUDIT
> >  [0]  AUDIT   0x5cthread
> >
> > The -p is peeled off, and its optarg used to define an auditor.
> > Again, probably not what the user wanted.
> >
> > The Studio compilers can behave slightly differently in that
> > they can affect the options passed to ld(1):  For example
> >
> > % cc -o null.so -G -thread null.o
> >
> > results in ld(1) seeing distinct options '-t -hread'.
> >
> > Given these are "bad" options to ld(1), it would be helpful
> > to our Userland developers if ld(1) could recognize them
> > rather than falling through to getopt() processing, where the
> > options are mis-interpreted and "might" result in an error
> > depending on the output file being produced.
>
> The attached patch (libtool-Solaris-ld.patch) prevents '-pthread' from
> being
> passed to ld on solaris2 hosts.
>
>
> _Originally posted to_ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34076
>
>
>
>
> ___
>
> File Attachments:
>
>
> ---
> Date: Mon 20 Sep 2021 10:24:04 AM UTC  Name: libtool-Solaris-ld.patch
> Size:
> 902B   By: staceym
> Patch file
> 
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via Savannah
>   https://savannah.gnu.org/
>
>
>

Re: trouble in porting CLAMAV to IBN/AS400 Linux

[Robert Boehne]

Isaac,

It appears that you're linking with "ld" instead of the compiler driver
"gcc" - but there is precious little information to go on here.  For
example, you're saying "AS400 Linux", but those two are mutually
exclusive.  Looking at the CLAMAV website, it makes no mention of os400
support, so you might want to start with asking for help from the CLAMAV
maintainers.

HTH,

Rob Boehne


On Wed, Dec 4, 2019 at 8:00 AM Isaac Oren  wrote:

>
> quite new to OpenSource and GNU... any support will be appreciated...
>
> While building CLAMAV version: clamav-0.102.0 on IBM/AS400 Linux
> environment  (similar to AIX)
>
> The Make echoed the following info and stopped... There was a problem with
> the libtool which (probably) caused the linker to fail...
>
> here are the last part of the make output... any help will be greatly
> appreciated...
>
>
>
> --
>
> libtool:   error: not configured to extract global symbols from
> dlpreopened f
> iles
>
> ld: 0711-224 WARNING: Duplicate symbol: .__init_aix_libgcc_cxa_atexit
>
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information
> .
>
> ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0
>
> ld: 0711-317 ERROR: Undefined symbol: vtable for
> __cxxabiv1::__si_class_type_
> info
>
> ld: 0711-317 ERROR: Undefined symbol: vtable for
> __cxxabiv1::__class_type_inf
> o
>
> ld: 0711-317 ERROR: Undefined symbol: .flock
>
> ld: 0711-317 ERROR: Undefined symbol: .operator delete(void*, unsigned
> long)
> ld: 0711-317 ERROR: Undefined symbol: .operator deleteÄÜ(void*)
>
> ld: 0711-317 ERROR: Undefined symbol: .operator newÄÜ(unsigned long)
>
>
>
> --
>
>  host-triplet:   powerpc-ibm-os400
>   shell:  /bin/sh
>
>   compiler:   gcc
>
>   compiler flags: -DP_tmpdir=/SMZVDTA1020/tmp -DC_AIX
> -DHAVE_IN_PORT_T -
>DHAVE_IN_ADDR_T -DHAVE_DIRENT_H -fno-strict-aliasing
>  -D_LARGEFILE_SOURCE -D_
>LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
>
>   linker: /QOpenSys/usr/bin/ld (gnu? no)
>
>   version:libtool (GNU libtool) 2.4.6 Debian-2.4.6-2
>
>   automake:
>
>   autoconf:
>
>

Re: Cut a new release?

[Robert Boehne]

I would be more than happy to cut a release, if only I could remember how.
I think the last version I released was 1.5.x - I'll look around but if
anyone on the list remembers where the instructions are - please help me
out ;)

Thanks,

Rob Boehne

On Fri, Sep 21, 2018 at 5:50 AM Samuel Tardieu  wrote:

> Hi.
>
> Since libtool latest release 3 years ago, some important problems have
> been patched. In particular, "-fuse-ld=…" is now propagated to the
> driver when linking.
>
> For example, it is not possible to build LLVM modules using libtool on
> Ubuntu LTS using only released packages. "llvm-config --cxxflags"
> outputs "… -fuse-ld=gold -Wl,--no-keep-files-mapped …",  and only the
> linker option "--no-keep-files-mapped" is passed to the driver
> (g++/clang++) while "-fuse-gold=ld" is dropped, causing GNU ld to halt
> with an error because "--no-keep-files-mapped" is a gold-only option.
>
> This is a known problem which has been fixed in libtool repository in
> Feb. 2016 (f9970d99293faf908fdc153a653fa5781095fb7a), but no libtool
> release seems to have taken place since then.
>
> Would it be possible to cut a formal release?
>
>   Sam
>
>
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool problem

[Robert Boehne]

You are somehow mixing parts of libtool from different versions.  --tag has
been required since version 1.5, so some part of what you've built uses
something even older, circa 2002.  First, try re-generating the configury
for this project using newish tools.  'autoreconf" might do it.  You may
also contact the project for the package you are trying to build, you might
have missed some documentation that may tell you how to build it.

On Tue, Jun 26, 2018 at 4:09 PM, Alice Wonder  wrote:

> Hello,
>
> Very low bandwidth user, my only connection is using my phone as a hotspot
> which limits me to ~60 Kbits once I use the very low monthly allotment
> (that broadband users usually have used in two days)
>
> I have tried to search web for answers but it is very difficult as many
> sites pull in heavy third party resources.
>
> Okay -
>
> Platform: CentOS 7.5 x86_64 building inside of mock (necessary
> repositories locally mirrored while borrowing bandwidth from library, I can
> keep they rsynced at my slow speed at night so they are current)
>
> Software (audacity) - older version require insecure dependency EPEL
> removed due to its insecurity, building against newer results in GUI that
> doesn't work.
>
> Latest version of audacity requires GCC 4.9 or newer.
>
> So I built a GCC 5.5.0 w/ prefix of /opt/gnu - it's built w/o multilib and
> with just c,c++,objc,objc++ support (I probably only need the first two)
>
> With that gcc specified I get this error:
>
>
> -- terminal output --
> gtk/FileDialogPrivate.cpp: In function 'void 
> gtk_filedialog_ok_callback(GtkWidget*,
> FileDialog*)':
> gtk/FileDialogPrivate.cpp:103:22: warning: ignoring return value of 'int
> chdir(const char*)', declared with attribute warn_unused_result
> [-Wunused-result]
>  chdir(folder);
>   ^
> /bin/sh ./libtool--mode=link g++-L/opt/gnu/lib64 -L/lib64
> -L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
> libFileDialog_la-FileDialog.lo gtk/libFileDialog_la-FileDialogPrivate.lo
>   -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0   -lgtk-3
> -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0
> libtool: link: unable to infer tagged configuration
> libtool: link: specify a tag with `--tag'
> make[2]: *** [libFileDialog.la] Error 1
> -- /terminal output --
>
> Looking at http://metastatic.org/text/libtool.html from search results, I
> built libtool 2.4.2 (same version CentOS 7 has) rpm from pristine source
> but with a prefix of /opt/gnu and I built it using the gcc 5.5.0 in /opt/gnu
>
> Still get same error when specifying that libtool to audacity configure.
>
> Looking at audacity, seems they make their own libtool script. I read it
> trying to find where the error might be.
>
> Found the line
>
> -- code --
> sys_lib_dlsearch_path_spec="/lib /usr/lib /opt/gnu/lib64 "
> -- /code --
>
> Now after configure I try this but still get same error:
>
> -- code --
> sed -i -e 's?^sys_lib_dlsearch_path_spec="/lib
> /usr/lib?sys_lib_dlsearch_path_spec="/lib64 /usr/lib64?g' libtool
>
> -- /code --
>
> I know the gcc 5.5.0 build works, I tested that with simple
>
> echo 'int main(){}' > dummy.c
>
> I do however suspect the error is somewhere on my end. Any suggestions?
>
> Full environmental variables I'm passing to audacity configure script:
>
> -- code --
> LIBTOOL=/opt/gnu/bin/libtool CC=/opt/gnu/bin/gcc CXX=/opt/gnu/bin/g++
> CPP=/opt/gnu/bin/cpp LDFLAGS="-L/opt/gnu/lib64"
> CPPFLAGS="-I/opt/gnu/include"
> -- /code --
>
>
> --
> You have to be a deviant or exist in dreary boredom. Make no mistake; all
> intellectuals are deviants -- William S. Burroughs
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: error: only absolute run-paths are allowed

[Robert Boehne]

The problem appears to be the "-rpath" flag without an argument.

Please post your version of Libtool and your platform's configuration (gcc,
ld, OS etc.).

On Mon, Apr 2, 2018 at 11:36 AM, Jordy Dickinson  wrote:

> I'm trying to convert a PAM module's build system to an autotools
> project, and I'm having issues with libtool. The output of `make` is as
> follows:
>
> ```
> [...]
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc  -g -O2 -module -no-
> undefined -avoid-version  -o pam_panic.la -rpath  pam_panic.lo
> pam_panic_authdevice.lo pam_panic_password.lo pam_panic_reject.lo
> libtool:   error: only absolute run-paths are allowed
> make[2]: *** [Makefile:449: pam_panic.la] Error 1
> make[2]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make[1]: *** [Makefile:496: all-recursive] Error 1
> make[1]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make: *** [Makefile:388: all-recursive] Error 1
> ```
>
> Here's my configure.ac:
>
> ```
> AC_INIT([pam_panic], [0.1.0], [], [pam_panic])
> AC_CONFIG_AUX_DIR([build-aux])
> AM_INIT_AUTOMAKE([-Wall])
> AC_PREREQ([2.69])
> AC_CONFIG_MACRO_DIR([m4])
> AC_CANONICAL_HOST
>
> AC_SUBST(PACKAGE)
> AC_SUBST(VERSION)
>
> AC_USE_SYSTEM_EXTENSIONS
> AC_PROG_CC
> AM_PROG_AR
>
> AC_PATH_PROG([REBOOT], [reboot])
> AC_SUBST(REBOOT)
> AC_PATH_PROG([POWEROFF], [poweroff])
> AC_SUBST(POWEROFF)
> AC_PATH_PROG([CRYPTSETUP], [cryptsetup])
> AC_SUBST(CRYPTSETUP)
>
> AC_ARG_ENABLE(securedir,
> AS_HELP_STRING([--enable-securedir=DIR],
> [path to location of PAMs @<:@default=$libdir/security@:>@]),
> SECUREDIR=$enableval, SECUREDIR=$libdir/security)
> AC_SUBST(SECUREDIR)
>
> LT_INIT([disable-static])
> AC_ENABLE_STATIC([no])
> AC_ENABLE_SHARED([yes])
>
> AC_CONFIG_FILES([
> Makefile
> src/pam_panic/config.h
> src/pam_panic/Makefile
> src/pam_panic/man/Makefile
> src/pam_panic_pw/config.h
> src/pam_panic_pw/Makefile
> src/pam_panic_pw/man/Makefile
> ])
>
> AC_OUTPUT
> ```
>
> Here's Makefile.am:
>
> ```
> ACLOCAL_AMFLAGS = -I m4
> CLEANFILES = *~
>
> SUBDIRS = src/pam_panic src/pam_panic_pw
> ```
>
> Finally, src/pam_panic/Makefile.am:
>
> ```
> SUBDIRS = man
>
> securelibexecdir = $()
>
> securelibexec_LTLIBRARIES = pam_panic.la
> pam_panic_la_SOURCES = \
> pam_panic.c \
> pam_panic_authdevice.c \
> pam_panic_password.c \
> pam_panic_reject.c
> pam_panic_la_LDFLAGS = -module -no-undefined -avoid-version
> ```
>
> Any help would be appreciated.
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: staging dir (DESTDIR)

[Robert Boehne]

Tomek,

I don't think I could get very far with what you've provided so far.  Can
you post a simplified example that demonstrates the problem?

Thanks,

Robert Boehne

On Mon, Jul 3, 2017 at 12:17 PM, Tomek Bury <tomek.b...@gmail.com> wrote:

> Hi,
>
> Is there any way to make libtool play nicely with cross-compiled
> dependencies in temporary staging directory? I'm trying to build Weston
> which requires wayland which, in turn, requires ffi. Libtool correctly
> finds the 1st-level dependencies (wayland) but then fails on libffi.
>
> In theory it should Just Work (TM) but in practice libtool tries to use
> sed on /usr/local/lib/libffi.la (I've configured with
> --prefix=/usr/local) which doesn't exist.
>
> Cheers,
> Tomek
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: disable indirect dependency linking

[Robert Boehne]

Not to my knowledge.  Libtool does this to support the use of "static"
libraries, which generally require all of the indirect and direct
dependencies, in the correct order (including duplicates), to be provided
on the command line at link time.
For a shared library link, this can, on some platforms, add data to the
output binary that may not necessary on every platform but remember, the
purpose of Libtool is not to provide optimal linking on your platform, but
to provide portability across platforms.

HTH,

Robert Boehne

On Mon, Feb 6, 2017 at 7:02 PM, Sashan Govender <sash...@gmail.com> wrote:

> Hi
>
> How do I tell libtool not to recursively add dependant libraries to
> the list of libraries to link with. For example, say I have a program
> A, that depends on libfoo and libfoo depends on libbar. In my
> Makefile.am  for A I have a line like this:
>
> A_LDDADD= libfoo.la
>
> Behind the scenes libtool will figure out that libfoo depends on
> libbar and so after linking the resultant binary contains information
> showing that A depends on  libfoo and libbar. (i.e. output from
> objdump -p A | grep NEEDED shows both libraries). Since libbar is an
> indirect dependency of A, libtool has added it. Can this be disabled
> such that only the direct dependencies are included?
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: How to make a C++ -module?

[Robert Boehne]

Patrick,

Did you build the compiler yourself?  Basically Libtool is saying you only
have a static version of your runtime library, so if you built the compiler
yourself, add --enable-shared when you configure.  If not, I'll see if I
can get a NetBSD VM up and running so I can reproduce your problem, but at
first glance it appears to be your compiler.

Robert
On Jun 21, 2016 8:58 AM, "Bob Friesenhahn" 
wrote:

> On Tue, 21 Jun 2016, Patrick Welche wrote:
>
> I'm trying to create a C++ loadable module. I thought it would be as easy
>> as:
>>
>
> [ stuff removed ]
>
> This fails with:
>>
>> /bin/sh ./libtool  --tag=CXX   --mode=link g++  -g -O2 -module
>> -avoid-version  -o hellow.la -rpath /usr/local/lib hellow.lo
>>
>> *** Warning: linker path does not have real file for library -lgcc.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libgcc and none of the candidates passed a file format test
>> *** using a regex pattern. Last file checked: /usr/lib/libgcc.a
>>
>> Presumably, this means that things aren't as simple as I thought.
>> What am I missing?
>>
>
> Nothing is easy when it comes to C++-based modules.  Risks are elevated if
> a C-based program uses C++-based modules due to unhandled C++ exceptions or
> C++ exceptions possibly not working.
>
> You are going to need a shared library for the (correct) C++ run-time as
> well as libgcc_s.so.  These need to somehow appear where libtool is
> searching for them.  They will also need to be available in a path where
> the system searches for shared libraries in order to load the module.
>
> # Dependencies to place before and after the objects being linked to
>> # create a shared library.
>> predep_objects="/usr/lib/crti.o /usr/lib/crtbeginS.o"
>> postdep_objects="/usr/lib/crtendS.o /usr/lib/crtn.o"
>> predeps=""
>> postdeps="-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc"
>>
>
> I am not sure what libgcc is used for.  It seems to only ever be delivered
> as a static library in the GCC installation tree.  Its appearance in the
> link line may be a bug (possibly a bug in GCC).
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Why is this library not found?

[Robert Boehne]

I'd guess that the 2nd file not found error is a library that gneural
depends on.

Also, you may want to build your library with -module, as that seems
consistent with your use case.

Hth,

Robert
On May 1, 2016 5:11 PM, "Aljosha Papsch" <li...@rpapsch.de> wrote:

On 01.05.2016 21:00, Mike Frysinger wrote:

> On 01 May 2016 09:18, Robert Boehne wrote:
>
>> Run it under gdb and see why it doesn't find the library.
>>
> or use strace -- that'll show quickly all the files/paths that the
> program is trying to use
> -mike
>
thanks, I underestimated strace until now. I executed following commands:

* Library name "gneural" and command LD_LIBRARY_PATH=/opt/gneural/lib
strace ./dlopen

access("/opt/gneural/lib/gneural", R_OK) = -1 ENOENT (No such file or
directory)
access("/usr/lib/gneural", R_OK)= -1 ENOENT (No such file or
directory)
access("/usr/lib32/gneural", R_OK)  = -1 ENOENT (No such file or
directory)
open("/opt/gneural/lib/gneural", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=259355, ...}) = 0
mmap(NULL, 259355, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc386998000
close(3)= 0
open("/usr/lib/tls/x86_64/gneural", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
[...]
open("/usr/lib/gneural", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=169152, ...}) = 0
munmap(0x7fc386998000, 259355)  = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
write(1, "file not found\n", 15file not found
)= 15
exit_group(0)   = ?
+++ exited with 0 +++

* Name "gneural" and command LD_LIBRARY_PATH= strace ./dlopen

It doesn't even look in /opt/gneural/lib, even though directory is in
/etc/ld.so.conf.d file.

* Name "libgneural.so" and command LD_LIBRARY_PATH=/opt/gneural/lib strace
./dlopen

I tried this name because strace shows that it uses the name verbatim
without some magic.

open("/opt/gneural/lib/libgneural.so", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\\30\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=125152, ...}) = 0
mmap(NULL, 2132376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f55cfd54000
mprotect(0x7f55cfd5d000, 2093056, PROT_NONE) = 0
mmap(0x7f55cff5c000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7f55cff5c000
close(3)= 0
munmap(0x7f55d08ef000, 259355)  = 0
munmap(0x7f55cfd54000, 2132376) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
write(1, "file not found\n", 15file not found
)= 15
exit_group(0)   = ?
+++ exited with 0 +++

It opens the library but still reports that file is not found. Do you know
why? Also, despite Roberts remark about removing lib prefix, I had to
specify full name. Why is that?

Best regards
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Why is this library not found?

[Robert Boehne]

Run it under gdb and see why it doesn't find the library.
On May 1, 2016 9:13 AM, "Aljosha Papsch" <li...@rpapsch.de> wrote:

> Hi,
>
> unfortunately it doesn't work without the lib prefix either. I tried quite
> a few combinations:
> libgneural
> libgneural-0.0.0
> gneural
> gneural-0.0.0
> gneural-0
>
> From distant memory I recalled that ldconfig needs to be executed to avoid
> LD_LIBRARY_PATH. So I created a conf file for ldconfig at
> /etc/ld.so.conf.d/gneuralnetwork.conf (I'm on Parabola):
> /opt/gneural/lib
>
> But I'm out of luck. Do you have any other hints?
>
> On 01.05.2016 16:05, Robert Boehne wrote:
>
> The string you pass to Lt_dlopen should not contain the "lib" prefix.
> On May 1, 2016 7:12 AM, "Aljosha Papsch" <li...@rpapsch.de> wrote:
>
>> Hello,
>>
>> I librarified gneural_network, patches pending at:
>> https://lists.gnu.org/archive/html/gneuralnetwork/2016-04/msg00015.html
>> In that patch library is called libgneural_network, locally I modified
>> name to libgneural.
>>
>> Next I installed gneural_network at /opt:
>>
>> /opt/gneural/
>> ├── bin
>> │   └── gneural_network
>> ├── include
>> │   └── gneural
>> │   ├── activation.h
>> │   ├── binom.h
>> │   ├── defines.h
>> │   ├── error.h
>> │   ├── fact.h
>> │   ├── feedforward.h
>> │   ├── genetic_algorithm.h
>> │   ├── gradient_descent.h
>> │   ├── includes.h
>> │   ├── load.h
>> │   ├── msmco.h
>> │   ├── parser.h
>> │   ├── randomize.h
>> │   ├── random_search.h
>> │   ├── rnd.h
>> │   ├── save.h
>> │   ├── simulated_annealing.h
>> │   └── structures.h
>> └── lib
>> ├── libgneural.a
>> ├── libgneural.la
>> ├── libgneural.so -> libgneural.so.0.0.0
>> ├── libgneural.so.0 -> libgneural.so.0.0.0
>> └── libgneural.so.0.0.0
>>
>> I try to load that library with lt_dlopen:
>>
>> #include 
>> #include 
>>
>> int
>> main (int argc, char** argv)
>> {
>>   lt_dlhandle handle;
>>   lt_dlinit ();
>>   handle = lt_dlopen ("libgneural");
>>   if (handle != NULL)
>> {
>>   printf ("Loaded library\n");
>>   lt_dlclose (handle);
>> }
>>   else
>> {
>>   printf (lt_dlerror ());
>>   printf ("\n");
>> }
>>   return 0;
>> }
>>
>> This program fails with error message: file not found. What am I doing
>> wrong? The command line is:
>> $ gcc -l ltdl -o dlopen dlopen.c
>> $ LD_LIBRARY_PATH=/opt/gneural/lib ./dlopen
>>
>> Best regards
>> Aljosha Papsch
>>
>> ___
>> https://lists.gnu.org/mailman/listinfo/libtool
>>
>
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Linking libtool created .la to shared library .dylib

[Robert Boehne]

Because Libtool was not used to create libB.dylib, it does not know how to
adjust the environment to find it.  You have to do that.
You can put the path to libB in your environment, or you can add a flag to
hard-code that path when libA.la is used.

Do that by adding an RPATH specification like this:

libA_la_LIBADD = $(LIBM) -Ldir/to/ -rpath dir/to/ -lB

Hope that solves your issue.

Robert Boehne
On Oct 6, 2015 3:39 PM, "Jacob Barthelmeh" <ja...@wolfssl.com> wrote:

> Hello,
>
> Am stumped on a link. Even after pouring over the manuals for hours and
> searching online it is probably a misunderstanding of autotools.
>
> I have one .la library made by libtool, one .dylib shared library and am
> creating a program. The .la is linked to the .dylib and the program uses
> the .la.
>
> Makefile.am for the .la library
>
> lib_LTLIBRARIES = libA.la libA_la_LDFLAGS = ${AM_LDFLAGS} -no-undefined
> libA_la_LIBADD = $(LIBM) -Ldir/to/ -lB libA_la_CPPFLAGS = ${AM_CPPFLAGS}
>
> Makefile.am for program with libtool wrapper
>
> noinst_PROGRAMS = test test_SOURCES = test_source.c test_LDADD = libA.la
> -Ldir/to/ -lB
>
> libA.la is created and links to B.dylib but the test program "wrapper"
> created by automake is exporting DYLD_LIBRARY_PATH to find libA.la while
> not linking to B.dylib. Giving the error
>
> dyld: Library not loaded: ./B.dylib Referenced from:
> /dir/to/test/.libs/test Reason: image not found Trace/BPT trap: 5
>
> Some things that I have tried are adding "-Ldir/to/ -lB" to test_LDFLAGS
> in addition to already being added in test_LDADD. And have tried setting
> test_LDFLAGS = -rpath -Ldir/to in the hopes that setting the runtime search
> path to the directory where B.dylib is would help.
>
> If I manually export DYLD_LIBRARY_PATH to include /dir/to/B.dylib then the
> test program is able to run but I'm looking to have autotools take care of
> this rather than requiring someone to export a path before being able to
> run it. Any tips or ideas would be greatly appreciated.
>
> Regards, Jacob
> Jacob Barthelmeh
> www.wolfssl.com
> ja...@wolfsssl.com
> 406-231-1496
> Skype: jacob_bart
>
>
>
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

[Robert Boehne]

So if I read these correctly, you specify the runtime path with -R but not
the link time location with -L ?  Does too run without help if you specify
both when you build your Libtool library?

Robert Boehne
On Feb 11, 2015 2:39 PM, Bert Wesarg bert.wes...@googlemail.com wrote:

 Hi,

 On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
 marcin.zalew...@gmail.com wrote:
  Hello.
 
  I have a contrib jemalloc library in my project that is not being
  built using libtool. When I build my libtool library, I add this to
  the link line:
 
  -ljemalloc -R/rpath/to/jemalloc
 
  This works fine, and my .la file includes:
 
  dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'
 
  However, when I link my programs with the .la file, I do not get rpath
  on the liker line, which causes a run-time failure when the program is
  run. Am I using the -R option correctly? I was hoping that I could
  make it a dependency in my .la file and not have to worry about it.
  The documentation for -R says:
 
  If output-file is a program, add libdir to its run-time path. If
  output-file is a library, add -Rlibdir to its dependency_libs, so
  that, whenever the library is linked into a program, libdir will be
  added to its run-time path.
 
  As far as I understood this, once my library has this dependency, the
  rpath will be added to any program that links to my library, but that
  is not happening.

 this is a known problem, though it seems that it is not considered as
 one by the libtool team:

 http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

 Bert

 
  Any help would be appreciated,
  -m

 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: AM_LDFLAGS += -no-undefined

[Robert Boehne]

While I agree with Bob, we should all build everything with all symbols
resolved, I also do not believe ltdl should force this on everything in a
project.  So I'm inclined to give thumbs up to a patch that fixes that.

Robert Boehne
On Apr 8, 2014 9:53 AM, Akim Demaille a...@lrde.epita.fr wrote:

 Hi Bob!

 Le 8 avr. 2014 à 16:28, Bob Friesenhahn bfrie...@simple.dallas.tx.us a
 écrit :

  On Tue, 8 Apr 2014, Akim Demaille wrote:
 
  This option is necessary in order to build DLLs under Windows (and
 likely shared libraries under AIX).

 I do understand it is needed on some platforms, but I
 don't aim at these.

  It expects a commitment to supply all dependency libraries at
 library/module link time.

 Which almost means additional dependencies and time spent
 in relinking.  Which I try to avoid as much as possible.

  You could edit the copy of libltd/Makefile.inc in your project if it
 causes an issue for you but there may be consequences for platforms which
 need it.

 Yes, I know.  But still, to me it looks like something which
 is probably not meant to be.  After all, it decides for the
 whole package what options should be passed for all libraries.

 It should rather be scoped to libltdl only, and the documentation
 should emphasize the relevance of -no-undefined (which it already
 does).

  GraphicsMagick uses a non-recursive build and used to build libltdl as
 part of the build (for at least 8 years).  Even though ltdl added
 -no-undefined it was not a problem since GraphicsMagick was intentionally
 using this option.
 
  Since then, I realized that building libltdl as part of the project was
 prohibitive, costly, and dangerous.  It was better to rely on libltdl to be
 a formally installed dependency on the system. Now GraphicsMagick treats
 libltdl just like any other external library and life is much improved.  I
 would encourage any other package to not bundle libltdl and to simply
 document that it must already be installed on the system.

 What do you mean by dangerous?  In case of mixture of versions I guess?
 This is probably a problem for libraries that likely to be linked in
 a program that links with even more libraries.

 And for prohibitive and costly, I'd be happy too to have some details :)
 It's not too big, and very fast to build (compared to the remainder
 of my severely-templated C++ libraries, it is perfectly negligible).
 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool - warnings when installing GMP using DESTDIR

[Robert Boehne]

The relinking warning is just to let you know it is linking, it isn't a
potential problem.

Robert Boehne
On Sep 19, 2013 6:21 PM, Michael Young young@gmail.com wrote:

 I was originally going to post this to the gmp-discuss list, but after
 reviewing
 it, it seems like it fits better here.  Please kindly redirect me if this
 is
 better handled elsewhere...

 I'm trying to do a staged build/install of libgmp(xx) release 5.1.2.  This
 is
 part of an effort to develop a general build system (mostly bash
 scripts, make
 files, etc.) for toolchains I will be using.  I intend to use these
 scripts to
 build both native and cross-builds, depending on configuration /
 arguments, so
 using DESTDIR for prefixing the install tree is important.  Right now, I'm
 working on native builds on an Ubuntu 12.04 32-bit x86 machine; libtool
 version = 2.4.2.)

 When building/installing gmp, I use DESTDIR with make install (as follows,
 with
 the configured prefix being
 /home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install), as
 follows:

make install DESTDIR=/home/youngmj/tmp

 I get the following warning / output:

 ***
   *snip*
 libtool: install: warning: relinking `libgmpxx.la'
 libtool: install: (cd
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/build;
 /bin/bash
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/build/libtool
  --tag CXX --mode=relink g++ -version-info 7:2:3 -o libgmpxx.la -rpath
 /home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib dummy.lo
 cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo
 cxx/limits.lo cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo
 cxx/osmpz.lo libgmp.la -inst-prefix-dir /home/youngmj/tmp)
 libtool: relink: g++  -fPIC -DPIC -shared -nostdlib
 /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o
 /usr/lib/gcc/i686-linux-gnu/4.6/crtbeginS.o  .libs/dummy.o
 cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o cxx/.libs/ismpz.o
 cxx/.libs/ismpznw.o cxx/.libs/limits.o cxx/.libs/osdoprnti.o
 cxx/.libs/osfuns.o cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o
 -Wl,-rpath
 -Wl,/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
 -L/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
 -L/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib -lgmp
 -L/usr/lib/gcc/i686-linux-gnu/4.6
 -L/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu
 -L/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib -L/lib/i386-linux-gnu
 -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L.
 -L/usr/lib/gcc/i686-linux-gnu/4.6/../../.. -lstdc++ -lm -lc -lgcc_s
 /usr/lib/gcc/i686-linux-gnu/4.6/crtendS.o
 /usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o
  -Wl,-soname -Wl,libgmpxx.so.4 -o .libs/libgmpxx.so.4.3.2
 libtool: install: /usr/bin/install -c .libs/libgmpxx.so.4.3.2T
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.so.4.3.2
 libtool: install: (cd
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
  { ln -s -f libgmpxx.so.4.3.2 libgmpxx.so.4 || { rm -f libgmpxx.so.4 
 ln -s libgmpxx.so.4.3.2 libgmpxx.so.4; }; })
 libtool: install: (cd
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
  { ln -s -f libgmpxx.so.4.3.2 libgmpxx.so || { rm -f libgmpxx.so  ln -s
 libgmpxx.so.4.3.2 libgmpxx.so; }; })
 libtool: install: /usr/bin/install -c .libs/libgmpxx.lai
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/
 libgmpxx.la
 libtool: install: /usr/bin/install -c .libs/libgmp.a
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
 libtool: install: chmod 644
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
 libtool: install: ranlib
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
 libtool: install: /usr/bin/install -c .libs/libgmpxx.a
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
 libtool: install: chmod 644
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
 libtool: install: ranlib
 /home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
 libtool: install: warning: remember to run `libtool --finish
 /home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib'
   *snip*
 

 [BTW - the T in the .so library version (4th line) looks wierd... can
 anyone
 verify this is OK?]

 The second warning is not the primary problem - I run the finish command
 once I
 move the installation into place.  The first warning (relinking) is what
 I'm most
 concerned about. I see where the warning is coming from - the following is
 in
 libgmpxx.la after the build and verification (make check), but prior to
 install

Re: Libtool library used but 'LIBTOOL' is undefined

[Robert Boehne]

You seem to have mismatched bits of Makefiles and configure.  To install,
you should simply unpack a tar ball and run configure.  It looks like you
have regenerated some of these things on an inconsistent way.

HTH,

Robert Boehne
On Sep 20, 2013 10:35 AM, Giuseppe Aprea giuseppe.ap...@gmail.com wrote:

 Hi all,

 I have a problem during mesalib installation which seems connected with
 libtool. I guess the problem may be due to my environment since I have
 automake and libtool installed in non-standard places.

 libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
 (version=2.4.2)
 automake is under ${GLOBAL_PREFIX}/automake/${AUTOMAKE_VERSION}
 (version=1.12.6)
 pkg-config is under ${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG_VERSION}
 (version=0.28)

 trying to install mesalib under ${GLOBAL_PREFIX}/mesalib/${MESALIB_VERSION},
 during make I receive lots of errors like:

 src/mesa/drivers/dri/radeon/Makefile.am:42:   The usual way to define
 'LIBTOOL' is to add 'LT_INIT'
 src/mesa/drivers/dri/radeon/Makefile.am:42:   to 'configure.ac' and run
 'aclocal' and 'autoconf' again.
 src/mesa/drivers/dri/radeon/Makefile.am:42:   If 'LT_INIT' is in '
 configure.ac', make sure
 src/mesa/drivers/dri/radeon/Makefile.am:42:   its definition is in
 aclocal's search path.
 src/mesa/drivers/dri/swrast/Makefile.am:39: error: Libtool library used
 but 'LIBTOOL' is undefined
 src/mesa/drivers/dri/swrast/Makefile.am:39:   The usual way to define
 'LIBTOOL' is to add 'LT_INIT'
 src/mesa/drivers/dri/swrast/Makefile.am:39:   to 'configure.ac' and run
 'aclocal' and 'autoconf' again.
 src/mesa/drivers/dri/swrast/Makefile.am:39:   If 'LT_INIT' is in '
 configure.ac', make sure
 src/mesa/drivers/dri/swrast/Makefile.am:39:   its definition is in
 aclocal's search path.
 src/mesa/drivers/osmesa/Makefile.am:35: error: Libtool library used but
 'LIBTOOL' is undefined
 src/mesa/drivers/osmesa/Makefile.am:35:   The usual way to define
 'LIBTOOL' is to add 'LT_INIT'
 src/mesa/drivers/osmesa/Makefile.am:35:   to 'configure.ac' and run
 'aclocal' and 'autoconf' again.
 src/mesa/drivers/osmesa/Makefile.am:35:   If 'LT_INIT' is in 'configure.ac',
 make sure
 src/mesa/drivers/osmesa/Makefile.am:35:   its definition is in 
 aclocal'ssearch path.
 src/mesa/drivers/x11/Makefile.am:35: error: Libtool library used but
 'LIBTOOL' is undefined
 src/mesa/drivers/x11/Makefile.am:35:   The usual way to define 'LIBTOOL'
 is to add 'LT_INIT'
 src/mesa/drivers/x11/Makefile.am:35:   to 'configure.ac' and run
 'aclocal' and 'autoconf' again.
 src/mesa/drivers/x11/Makefile.am:35:   If 'LT_INIT' is in 'configure.ac',
 make sure
 src/mesa/drivers/x11/Makefile.am:35:   its definition is in aclocal'ssearch 
 path.
 src/mesa/libdricore/Makefile.am:68: error: Libtool library used but
 'LIBTOOL' is undefined
 src/mesa/libdricore/Makefile.am:68:   The usual way to define 'LIBTOOL'
 is to add 'LT_INIT'
 src/mesa/libdricore/Makefile.am:68:   to 'configure.ac' and run 'aclocal'
 and 'autoconf' again.
 src/mesa/libdricore/Makefile.am:68:   If 'LT_INIT' is in 'configure.ac',
 make sure
 src/mesa/libdricore/Makefile.am:68:   its definition is in aclocal'ssearch 
 path.
 src/mesa/program/Makefile.am:41: error: Libtool library used but
 'LIBTOOL' is undefined
 src/mesa/program/Makefile.am:41:   The usual way to define 'LIBTOOL' is
 to add 'LT_INIT'
 src/mesa/program/Makefile.am:41:   to 'configure.ac' and run 'aclocal'
 and 'autoconf' again.
 src/mesa/program/Makefile.am:41:   If 'LT_INIT' is in 'configure.ac',
 make sure
 src/mesa/program/Makefile.am:41:   its definition is in aclocal's search
 path.

 I am working on a cluster where i am supposed to install my stuff as
 non-root so I am forced to install in non-standard paths.I defined ACLOCAL
 =aclocal -I${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG_VERSION}/share/aclocal
 and then run configure and make; complete output is in attachment.

 It seems I need to define LT_INIT in configure.ac but it is already
 defined (from configure.ac in root meslib src folder):

 LT_PREREQ([2.2])
 LT_INIT([disable-static])

 I also tried to set LIBTOOL=${GLOBAL_PREFIX}/libtool/${LIBTOOL
 _VERSION}/bin/libtool but it didn't help.
 I would like to ask if anyone can give me any help, please.

 Any suggestion is welcome!

 Thanks in advance.







 ___
 https://lists.gnu.org/mailman/listinfo/libtool


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: problem with hardcode_libdir_flag_spec

[Robert Boehne]

Sorry - now that I've re-read your post I understand it better.

the Autoconf implementation of libdir is to refrain from expanding this
until make install time - so AC_SUBST([libdir])  clashes with that
implementation.  If it could be called a bug - that bug would be in
Autoconf, and might be fixed by having AC_SUBST have a list of all the
Autoconf-reserved names and rejecting any inconsistent of them.

HTH,

Robert



On Thu, Feb 7, 2013 at 6:02 AM, Werner LEMBERG w...@gnu.org wrote:


 This is a shy `ping' :-)


 Werner


 --


  [libtool 2.4.2]
 
  Folks,
 
 
  let's assume that someone is doing
 
AC_SUBST([libdir])
AC_SUBST([wl])
AC_SUBST([hardcode_libdir_flag_spec])
 
  and later tries to say
 
libdir = @libdir@
wl = @wl@
hardcode_libdir_flag_spec = @hardcode_libdir_flag_spec@
 
  within a Makefile, as can be done with other such variables.  [The
  idea is to construct a proper `-R' linker argument for a `--libs'
  option of a `foo-config' file generated at compile time, but this is a
  different issue.]
 
  However, this causes a very unpleasant surprise since the above
  snippet gets converted to
 
libdir = /foo/bar
wl = -Wl,
hardcode_libdir_flag_spec = '${wl}-rpath ${wl}$libdir'
 
  Note the `$libdir' string which gets interpreted as variable `$l'
  followed by `ibdir' within a Makefile...
 
  Now my questions.
 
. Is it a bug?  It should be trivial IMHO to use ${libdir} instead
  to avoid incorrect Makefile variable expansion.  I can imagine
  that other variables (even in autoconf or automake) are similarly
  affected.
 
. Is it correct usage?  I mean, is there a list of autotools
  variables which must not be used within a Makefile (after
  AC_SUBST)?
 
. How can I circumvent the problem with the current libtool version?
 
 
Werner

 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Is it possible to force GNU libtool to use the Solaris CC compiller instead of GCC?

[Robert Boehne]

./configure ... CXX=/opt/solarisstudio12.3/bin/CC
 CC=/opt/solarisstudio12.3/bin/cc


On Mon, Dec 10, 2012 at 5:44 AM, Frank Chang frank_chan...@hotmail.comwrote:

 Good morning, I was curious whether it is possible to force GNU libtool to
 use the Solaris CC compiller instead of GCC? If so, how might that be done?
 Thank you

 ___
 https://lists.gnu.org/mailman/listinfo/libtool


___
https://lists.gnu.org/mailman/listinfo/libtool

problems building git master under MinGW

[Robert Boehne]

Libtoolers,

Although libtool 2.4 and 2.4.2 built fine under MinGW w/ gcc/g++, with 
good test suite results (IIRC 5 fails/ 4 xfails)

I've not been able to get git master to build on this platform.

make  all-recursive
make[1]: Entering directory `/home/dev/gcc-lt'
Making all in .
make[2]: Entering directory `/home/dev/gcc-lt'
restore=:  backupdir=.am$$  \
am__cwd=`pwd`  CDPATH=${ZSH_VERSION+.}:  cd ../libtool  \
rm -rf $backupdir  mkdir $backupdir  \
if (/bin/sh /home/dev/libtool/build-aux/missing --run makeinfo 
--version) /dev/null 21; then \
  for f in ../libtool/doc/libtool.info 
../libtool/doc/libtool.info-[0-9] ../libtool/doc/libtool.info-[0-9][0-9] 
../libtool/doc/libtool.i[0-9] ../libtool/doc/libtool.i[0-9][0-9]; do \

if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi  \
cd $am__cwd; \
if /bin/sh /home/dev/libtool/build-aux/missing --run makeinfo -I 
doc -I ../libtool/doc \

 -o ../libtool/doc/libtool.info ../libtool/doc/libtool.texi; \
then \
  rc=0; \
  CDPATH=${ZSH_VERSION+.}:  cd ../libtool; \
else \
  rc=$?; \
  CDPATH=${ZSH_VERSION+.}:  cd ../libtool  \
  $restore $backupdir/* `echo ./../libtool/doc/libtool.info | sed 
's|[^/]*$||'`; \

fi; \
rm -rf $backupdir; exit $rc
../libtool/doc/libtool.texi:9: Unknown index `vr' and/or `cp ' in @synindex.
../libtool/doc/libtool.texi:10: Unknown index `fn' and/or `cp ' in 
@synindex.
../libtool/doc/libtool.texi:11: Unknown index `tp' and/or `cp ' in 
@synindex.
../libtool/doc/libtool.texi:12: Unknown index `pg' and/or `cp ' in 
@synindex.
makeinfo: Removing output file `../libtool/doc/libtool.info' due to 
errors; use --force to preserve.

make[2]: *** [../libtool/doc/libtool.info] Error 1
make[2]: Target `all-am' not remade because of errors.
make[2]: Leaving directory `/home/dev/gcc-lt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dev/gcc-lt'
make: *** [all] Error 2

makeinfo --version
makeinfo (GNU texinfo) 4.13

I worked around this by building on Linux, and scp'ing the doc 
directories contents to the windows 7 machine.

After that the test suite builds.

Thanks,

Robert Boehne


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: multiple inclusion of file

[Robert Boehne]

Steve,

Find out what the path for libstdc++.so is for the one you want,
then set LDFLAGS=-L/correct/path/  when you build the library that it's
complaining about.

Note that it may not be PCRE, but it could be something that PCRE links to.

Use ldd or ldd -s to find out which libraries are pulling in libstdc++
and from where.

HTH,

Robert

On Tue, Apr 24, 2012 at 11:13 AM, Gray, Steve, Wipro 
steve.gray.wi...@sonymusic.com wrote:

 Hello, I am in the process of trying to install the PCRE library.  I run
 the configure command with the various options, and I then run the make
 command, and this is when I get the error, “warning: file
 /usr/sfw/lib/libstdc++.so: attempted multiple inclusion of file”.  I am
 on a Solaris 10 operating system.  Have you seen this error message?  Is
 there something that I can do to get past this so that I can get the PCRE
 library installed?  How do I solve this?  If you have had this question
 asked before, I apologize for asking again, but I am at my rope’s end
 trying to get past this. I am new to PCRE, so if my questions seem
 irrelevant or pointless, I apologize.  I just need to get started. If you
 would like me to send you my configure options, I can do that, or any other
 information that you need from me, I’ll be glad to provide.

 ** **

 Thanks

 ** **

 ___
 https://lists.gnu.org/mailman/listinfo/libtool


image001.gif___
https://lists.gnu.org/mailman/listinfo/libtool

Re: multiple inclusion of file

[Robert Boehne]

Bob - correct on all counts :)

It can be problematic though, even when the two libstdc++.so files are
symlinks or otherwise identical.  If you provide libstdc++.so in a runtime
only package, you don't want the compiler's location to be hardcoded.  The
fix is to simply force a particular path with -L in LDFLAGS.

As I mentioned before though, it may be that a library your project depends
on that's actually hard coded the wrong path - Solaris ld will still
complain about what you're currently linking.  I don't think PCRE depends
on anything else that is c++ though, so it's probably coming from libtool
adding something different.

I'm not really a fan of Libtool adding an explicit dependency for libstdc++
really.  Libtool won't do this if you're using a different c++ compiler,
and the only case where this might help you out would be when your main
program isn't c++, and since Libtool doesn't help with this in that
situation, it probably shouldn't treat gcc as a special case.

HTH

On Tue, Apr 24, 2012 at 2:17 PM, Bob Friesenhahn 
bfrie...@simple.dallas.tx.us wrote:

 On Tue, 24 Apr 2012, Robert Boehne wrote:

  Steve,

 Find out what the path for libstdc++.so is for the one you want,
 then set LDFLAGS=-L/correct/path/  when you build the library that it's
 complaining about.

 Note that it may not be PCRE, but it could be something that PCRE links
 to.

 Use ldd or ldd -s to find out which libraries are pulling in
 libstdc++ and from where.


 I think that the situation is that when linking with the C++ compiler, the
 C++ compiler automatically adds linkage to its own libstdc++.so. Libtool
 also adds linkage to libstdc++.so (as a dependency) so the linker sees the
 (hopefully) same shared library listed twice.  There would be a severe
 problem if libtool was to request linking with a different libstdc++.so
 than the C++ compiler needs.

 Solaris ld warns about this issue, and presumably GNU ld does not.


 Bob
 --
 Bob Friesenhahn
 bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/**
 users/bfriesen/ http://www.simplesystems.org/users/bfriesen/
 GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: multiple inclusion of file

[Robert Boehne]

Run ldd -s on the resulting shared librry that generates the error.
It should show libstdc++.so coming from two different paths, and will also
show which share library each one is coming from.
I suspect that one of them is hardcoded in a file you're linking to (not
specified on your link line).

Robert

On Tue, Apr 24, 2012 at 2:47 PM, Gray, Steve, Wipro 
steve.gray.wi...@sonymusic.com wrote:

 In my configure statement I have “LDFLAGS=-L/usr/sfw/lib -R/usr/sfw/lib*
 ***

 I run the configure command with this option and I run the make command
 and I still get the “multiple inclusion of file error”

 ** **

 *From:* Robert Boehne [mailto:rboe...@gmail.com]
 *Sent:* Tuesday, April 24, 2012 3:12 PM

 *To:* Gray, Steve, Wipro
 *Cc:* libtool@gnu.org
 *Subject:* Re: multiple inclusion of file

 ** **

 Steve,


 Find out what the path for libstdc++.so is for the one you want,
 then set LDFLAGS=-L/correct/path/  when you build the library that it's
 complaining about.

 Note that it may not be PCRE, but it could be something that PCRE links to.

 Use ldd or ldd -s to find out which libraries are pulling in libstdc++
 and from where.

 HTH,

 Robert

 On Tue, Apr 24, 2012 at 11:13 AM, Gray, Steve, Wipro 
 steve.gray.wi...@sonymusic.com wrote:

 

 Hello, I am in the process of trying to install the PCRE library.  I run
 the configure command with the various options, and I then run the make
 command, and this is when I get the error, “warning: file
 /usr/sfw/lib/libstdc++.so: attempted multiple inclusion of file”.  I am
 on a Solaris 10 operating system.  Have you seen this error message?  Is
 there something that I can do to get past this so that I can get the PCRE
 library installed?  How do I solve this?  If you have had this question
 asked before, I apologize for asking again, but I am at my rope’s end
 trying to get past this. I am new to PCRE, so if my questions seem
 irrelevant or pointless, I apologize.  I just need to get started. If you
 would like me to send you my configure options, I can do that, or any other
 information that you need from me, I’ll be glad to provide.

  

 Thanks

  


 ___
 https://lists.gnu.org/mailman/listinfo/libtool

 ** **

image001.gif___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

[Robert Boehne]

These questions are quite common, and what they really come down to is that
many (or most) users want to solve a *different problem* than the one that
Libtool was designed to solve.

Libtool will deal with the platform specific vagaries of shared libraries
in a uniform manner.  It isn't designed to easily expose features of *some*
specific shared library implementions, but attempts to support the largest
common subset of features.
If you have a fairly simple packge that includes libraries, you may be able
to build  run it on CygWin with no changes (for example), and that is what
Libtool was designed to do.

Some that you mention below could be dealt with by adding them as new
features.

On Fri, Jan 6, 2012 at 12:31 PM, Peter O'Gorman pe...@pogma.com wrote:

 On 01/06/2012 11:21 AM, Stepan Kasal wrote:


 1) .la file always contains the recursively evaluated list of libraries.
 While this is necessary for static linking and dumb dynamic linkers,
 it is an issue for dyn. linkers that can do recursive resolution
 (which is the case on GNU/Linux distributions for many years).
 (I believe that the rule that forbids packing .la files to -dev and
 -devel subpackages on Debian and Fedora (respectively), is there just
 to work around this problem.)


 This is still an issue, libtool always adds all dependencies. Many
 packages assume this and don't explicitly add required dependencies to
 Makefile.am etc. I don't recall the arguments for not changing this when
 building shared. IIRC Scott tried to include Debian's patch at some point.
 I'll look it up in the archives later.


 Overlinking when using shared libraries is not a good thing, and Libtool
could be modified to have a list of all dependencies for the static case,
but when the platform supports it, it could also have a list with only the
first level of dependencies.


 2) People told me libtool is slow and shell has to parse huge script
 just to find out that it has to call gcc twice, with and without
 -fPIC.  Again, this is not about the general portability case, it is
 a request for optimization on GNU/Linux platform, that they percepts
 as one of the major customers of libtool.


 Libtool is faster than it used to be, the shell does have to parse quite a
 bit of script, but compile mode has been moved as close to the beginning of
 the script as possible to reduce that time, and the number of forks has
 been reduced drastically for modern shells. I believe dash and ksh93 are
 faster than bash at running libtool. Last time I checked, libtool's compile
 mode wasn't significantly slower than using dolt (
 http://dolt.freedesktop.org/)**.



 This could be optimized even more, but it would be a considerable amount
of work just to speed up compilation (Shouldn't we be spending more time
designeing code instead of building it?).



 3) Does it happen often in practice that a project builds both -fPIC
 and non-pic objects, even though only one of them is going to be
 used?  If yes, and if it is because of a mistake on package
 maintainer's side, can something be done about it?  (warnings, changed
 defaults, autodetection in automake)


 Perhaps the default should be --enable-shared --disable-static? It's worth
 considering.

 Peter


This is the common subset in action.  Some platforms can't make static
archives from PIC objects, so to make static and shared libraries, each
source file must be compiled twice.  Users can disable either one at
configure time, so Libtool is already doing everything it possibly can to
do what it should.  Changing the defaults would just cause a different
group of users to complain ;)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Unwanted shared runtime libraries getting added

[Robert Boehne]

I think the mode=compile line doesn't tell us much about what happens when
mode=link - post what you get on the libtool --mode=link command.

On Fri, Oct 8, 2010 at 1:22 PM, Ethan Mallove ethan.mall...@oracle.comwrote:

 On Fri, Oct/08/2010 07:50:39PM, Ralf Wildenhues wrote:
  * Ethan Mallove wrote on Fri, Oct 08, 2010 at 07:26:45PM CEST:
   On Fri, Oct/08/2010 07:14:18PM, Ralf Wildenhues wrote:
* Ethan Mallove wrote on Fri, Oct 08, 2010 at 02:42:53PM CEST:
 I'm trying to create a library which has no shared library
 dependencies using the Intel compilers, but it appears Libtool
 might
 be automatically adding in some -lfoo flags that are forcing the
 issue.  How can I tell Libtool to not add the -lfoo flags?
   
Which libraries are added?
  
   libimf and friends.
   
Which of those would you like to avoid?
  
   If possible, all of the Intel runtime libraries (e.g., libimf,
   libsvml, libintlc).
 
libtool normally adds all direct and indirect library dependencies
(the latter only when link_all_deplibs is true, which it currently is
everywhere except in the Debian-modified libtool), as well as
 compiler
support libraries.  The indirect deplibs is an obvious issue for at
least distributors, the rest is usually the right thing to do.
   
  
   So if I set link_all_deplibs to false, will that turn off the
   -limf -lsvml ... we're seeing in the link line?
 
  Nope.
 
  Does running the link command with --tag=CC fix that, i.e., avoid the
  libraries for you?

 I still get the libs that I don't want.  To ensure I did what you
 asked:

 $ /bin/sh ../../../libtool --tag=CC --mode=compile icpc -DHAVE_CONFIG_H -I.
 -I../../../opal/include -I../../../orte/include -I../../../ompi/include
 -I../../../opal/mca/paffinity/linux/plpa/src/libplpa
 -DOMPI_BUILDING_CXX_BINDINGS_LIBRARY=1 -DOMPI_SKIP_MPICXX=1 -I../../.. -O3
 -DNDEBUG -Wall -static-intel -m64 -finline-functions -fexceptions -pthread
 -MT comm.lo -MD -MP -MF \$depbase.Tpo -c -o comm.lo comm.cc
 libtool: compile:  icpc -DHAVE_CONFIG_H -I. -I../../../opal/include
 -I../../../orte/include -I../../../ompi/include
 -I../../../opal/mca/paffinity/linux/plpa/src/libplpa
 -DOMPI_BUILDING_CXX_BINDINGS_LIBRARY=1 -DOMPI_SKIP_MPICXX=1 -I../../.. -O3
 -DNDEBUG -Wall -static-intel -m64 -finline-functions -fexceptions -pthread
 -MT comm.lo -MD -MP -MF \$depbase.Tpo -c comm.cc  -fPIC -DPIC -o
 .libs/comm.o
 ...
 $ ldd .libs/libmpi_cxx.so
libmpi.so.0 = not found
libnsl.so.1 = /lib64/libnsl.so.1 (0x2af01713f000)
libutil.so.1 = /lib64/libutil.so.1 (0x2af017358000)
libimf.so = not found
libsvml.so = not found
libm.so.6 = /lib64/libm.so.6 (0x2af01755c000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x2af0177df000)
libirc.so = not found
libpthread.so.0 = /lib64/libpthread.so.0 (0x2af017ae)
libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x2af017cfb000)
libdl.so.2 = /lib64/libdl.so.2 (0x2af017f09000)
libc.so.6 = /lib64/libc.so.6 (0x2af01810e000)
/lib64/ld-linux-x86-64.so.2 (0x003fb700)
libintlc.so.5 = not found

 Thanks,
 Ethan

 
  Maybe we should just make postdeps et al overridable with a cache
  variable.
 
  Thanks,
  Ralf

 ___
 http://lists.gnu.org/mailman/listinfo/libtool

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: hpux linking shared library with static library

[Robert Boehne]

Libtool is intended to support a portable subset of shared library
functionality.  When you use an archive file to create a shared library,
this is generally not a portable feature, and won't work on many systems
(like Windows).

In this situation, you will be better off creating a shared library of the
archive you want to link in, or expanding it into it's object files and
linking them directly (like a Libtool convenience library).  But whatever
you may do, if you get an archive that isn't pic, it won't work, and because
the one advantage to static archives is that they don't have to be pic (and
may run a little faster) most of them are created from object files that are
not pic.

HTH,

Rob

On Wed, Jul 14, 2010 at 2:47 AM, Alon Bar-Lev alon.bar...@gmail.com wrote:

 ‎‎Thank you!

 But I do link the static library as PIC.

 Attached is a sample.

 When I remove the restriction all  works, shared can call static, main
 can call both.
 ---
 $ ldd xxx/bin/test1
 =
/usr/lib/libc.2 =  /usr/lib/libc.2
/usr/lib/libdld.2 =/usr/lib/libdld.2
/usr/lib/libc.2 =  /usr/lib/libc.2
/tmp/alon/test-1/xxx/lib/libb.sl = /tmp/alon/test-1/xxx/lib/
 libb.sl
/usr/lib/libc.2 =  /usr/lib/libc.2
 $ xxx/bin/test1
 ---

 ---
 AUTOMAKE_OPTIONS = foreign 1.10
 ACLOCAL_AMFLAGS = -I m4

 noinst_LTLIBRARIES = liba.la
 lib_LTLIBRARIES = libb.la
 bin_PROGRAMS = test1

 liba_la_SOURCES = a.c
 liba_la_CFLAGS = $(AM_CFLAGS) -prefer-pic
 liba_la_LDFLAGS= $(AM_LDFLAGS) -rpath $(libdir) -static

 libb_la_SOURCES = b.c libb.exports
 libb_la_LIBADD = liba.la
 libb_la_LDFLAGS = $(AM_LDFLAGS) \
-avoid-version -no-undefined \
-export-symbols $(srcdir)/libb.exports

 test1_SOURCES = c.c
 test1_LDADD = libb.la
 ---

 On Tue, Jul 13, 2010 at 7:30 PM, Robert Boehne rboe...@gmail.com wrote:
 
  When your shared library links, that doesn't mean it will work.  You
 would need to run a program with it, that uses symbols in the archive you've
 attempted to link to your shared library.
 
  IIRC, HPUX will generate non-pic by default and your link may not be
 resolving anything in the static archive.
 
 
  On Tue, Jul 13, 2010 at 11:09 AM, Alon Bar-Lev alon.bar...@gmail.com
 wrote:
 
  Hello,
 
  When I try to link shared library with static library on hpux I get
  the following message:
  
  *** Warning: This system can not link to static lib archive libcore.la.
  *** I have the capability to make that library automatically link in
 when
  *** you link to this library.  But I can only do this if you have a
  *** shared version of the library, which you do not appear to have.
  *** But as you try to build a module library, libtool will still create
  *** a static module, that should work as long as the dlopening
 application
  *** is linked with the -dlopen flag to resolve symbols at runtime.
  
 
  However if I change libtool:
  -deplibs_check_method=file_magic
  (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library
  +deplibs_check_method=pass_all
 
  It succeed in linking.
 
  Any reason why this is forbidden in hpux?
 
  $ uname -a
  HP-UX hpux1 B.11.11 U 9000/800 1528720528 unlimited-user license
 
  Regards,
  Alon Bar-Lev.
 
  ___
  http://lists.gnu.org/mailman/listinfo/libtool
 

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: hpux linking shared library with static library

[Robert Boehne]

When your shared library links, that doesn't mean it will work.  You would
need to run a program with it, that uses symbols in the archive you've
attempted to link to your shared library.

IIRC, HPUX will generate non-pic by default and your link may not be
resolving anything in the static archive.


On Tue, Jul 13, 2010 at 11:09 AM, Alon Bar-Lev alon.bar...@gmail.comwrote:

 Hello,

 When I try to link shared library with static library on hpux I get
 the following message:
 
 *** Warning: This system can not link to static lib archive libcore.la.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have.
 *** But as you try to build a module library, libtool will still create
 *** a static module, that should work as long as the dlopening application
 *** is linked with the -dlopen flag to resolve symbols at runtime.
 

 However if I change libtool:
 -deplibs_check_method=file_magic
 (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library
 +deplibs_check_method=pass_all

 It succeed in linking.

 Any reason why this is forbidden in hpux?

 $ uname -a
 HP-UX hpux1 B.11.11 U 9000/800 1528720528 unlimited-user license

 Regards,
 Alon Bar-Lev.

 ___
 http://lists.gnu.org/mailman/listinfo/libtool

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How to build a noinst_ but still shared library?

[Robert Boehne]

I didn't think convenience libraries were meant to result in shared libs,
just a bucket of object files with a convenient handle.

On Fri, Mar 19, 2010 at 7:35 PM, Dave Korn
dave.korn.cyg...@googlemail.comwrote:


Hi all,

  Well, here I am again with another dumb n00b question.  From the automake
 manual:

Libtool convenience libraries are declared by directory-less
 variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even
 `EXTRA_LTLIBRARIES'.  

  So: how do you build a shared library in your make check run, without it
 ending up installed somewhere during make install?  (In case it's
 relevant,
 the project is all flat in a single non-recursive Makefile, so I can't just
 e.g. force the subconfigure in tests/ to use a bogus $prefix choice under
 $objdir somewhere.)

cheers,
  DaveK


 ___
 http://lists.gnu.org/mailman/listinfo/libtool

___
http://lists.gnu.org/mailman/listinfo/libtool

[SCM] GNU Libtool annotated tag, release-1-4d, deleted. release-1-3d-238-g6be7c41

[Robert Boehne]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The annotated tag, release-1-4d has been deleted
   was  b6de51e77c1d5796b6aaf21655675d17fc2fc24d

---
tag release-1-4d
Tagger: Robert Boehne [EMAIL PROTECTED]
Date:   Mon Jan 7 22:09:42 2002 +

6be7c410015eca79d44a2d1c80081bae37f3fc93 * NEWS: Fixed wrong path for 
texinfo.tex. * configure.ac: Bumped version to 1.4e.
---


hooks/post-receive
--
GNU Libtool


___
Libtool-commit mailing list
Libtool-commit@gnu.org
http://lists.gnu.org/mailman/listinfo/libtool-commit

[SCM] GNU Libtool annotated tag, release-1-4d, created. release-1-4d

[Robert Boehne]

 is
  * libltdl/configure.ac (AM_INIT_AUTOMAKE): Bump libltdl version to
  * bootstrap: Be robust to having no files that need removing.
  * ltdl.m4 (AC_CHECK_HEADERS): Check for assert.h.
  * libltdl/ltdl.c: Added support for dmalloc, and uncovered some
  * libtool.m4 (archive_cmds) [darwin1.[0-2]]: Darwin uses zsh-3.1.6
  From Tor Lillqvist [EMAIL PROTECTED]:
  * libtool.m4 (_LT_AC_FILE_LTDLL_C): Be carefule that the start
  * libtool.m4 (AC_LIBLTDL_CONVENIENCE): s/INCLTDL/LTDLINCL/ for
  * configure.ac: General modernisation and cleanup.
  * ltdl.m4 (AC_WITH_LTDL): New macro to add `--with-included-ltdl'
  * libtool.m4 (_LT_AC_TAGCONFIG): Cray sed does not allow character
  From Tom Bates  [EMAIL PROTECTED]:
  From Joseph S. Myers  [EMAIL PROTECTED]:
  * libtoolize.in: The test for whether AC_PROG_LIBTOOL is defined

Guido Draheim (2):
  * libtool.m4 (mingw*) sys_lib_search_path_spec:
  * ltdl.m4: Changed underscode to underscore.

H.J. Lu (1):
  * ltmain.sh: Allow link against an archive when building a

Jens Petersen (1):
  * ltmain.in: Replace all test -as by  test

Kevin Ryde (2):
  *libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS): Remove a stray ' quote.
  * libtool.m4 (AC_LIBTOOL_SYS_MAX_CMD_LEN): Send test

Mark Kettenis (1):
  * libtool.m4 (AC_LIBTOOL_SYS_MAX_CMD_LEN) [gnu*]: Remove spurious

Mo DeJong (1):
  * ltmain.in: Place parens around a generated relink_command

NIIBE Yutaka (1):
  * libtool.m4 (lt_cv_deplibs_check_method): Use pass_all

Ossama Othman (3):
  From Thomas Poindessous [EMAIL PROTECTED]
  * libtool.m4 (AC_LIBTOOL_SETUP): Require Autoconf-2.50 via the
  * libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG): Corrected and improved

Raja R Harinath (1):
  * configure.ac (pkgdatadir): Move the invocation of AC_INIT_AUTOMAKE

Robert Boehne (10):
  * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS): add cases and comments for
  * libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS): Fix tag support
  * libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_LD_SHLIBS)
  * libtool.m4 (AC_LIBTOOL_PROG_COMPILER_PIC) [aix*]: Fixed an
  * libtool.m4 (mingw*) Revert the previous change as it was
  * libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) Fixed a problem
  * pdemo/Makefile.am (helldl):  Automake 1.4 can't find the target
  With help from Michael Matz [EMAIL PROTECTED]:
  * libtool.m4 (AC_LIBTOOL_SYS_MAX_CMD_LEN): Change the
  * NEWS: Fixed wrong path for texinfo.tex.

Steve Ellcey (2):
  * libtool.m4 (lt_cv_sys_global_symbol_to_cdecl):  Change it from
  * libtool.m4 (ia64-*-hpux*) Add support for ia64*-*-hpux* platform.

Tim Mooney (1):
  * libtool.m4 [osf3*, osf4*, osf5*]: Tru64 *can* build modules

Tim Van Holder (2):
  * libtool.m4 (_LT_AC_LIBTOOL_SYS_PATH_SEPARATOR): Remove.
  * ltdl.m4: Canonicalize descriptive text used with

Tor Lillqvist (3):
  * ltmain.in: Add a space to $base_compile in the case statement,
  ...forgot the other `case $base_compile' case in the submitted patch
  * libtool.m4 [mingw* cygwin*]: Small improvement for mingw-hosted

---


hooks/post-receive
--
GNU Libtool


___
Libtool-commit mailing list
Libtool-commit@gnu.org
http://lists.gnu.org/mailman/listinfo/libtool-commit

[SCM] GNU Libtool annotated tag, release-1-4-3, created. release-1-4-3

[Robert Boehne]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The annotated tag, release-1-4-3 has been created
at  c597de87aeeae26a8818ffd324b60c827882825d (tag)
   tagging  9dc578d6007e061f208a864c4c04a6d68c5f40aa (commit)
  replaces  release-1-4-2
 tagged by  Gary V. Vaughan
on  Thu Apr 17 12:56:17 2008 -0400

- Log -
1.4.3

Albert Chin-A-Young (15):
  * libltdl/ltdl.c: Match function return type with prototype
  * ltdl.m4 (AC_LTDL_DLLIB): Even though HP-UX 10.20 and 11.00
  * libltdl/ltdl.c: Match function return type with prototype
  * libltdl/ltdl.c (foreach_dirinpath): change some types to size_t
  * libtool.m4: quote LTCC because autoconf AC_PROG_CC_STDC
  * Use $ac_n and $ac_c rather than $ECHO_N and $ECHO_C for
  * ltmain.in: Fix version string under IRIX.
  * ltmain.in: Quote $pic_mode.
  * libtool.m4: Allow LT_AC_PROG_SED to work under autoconf
  * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS): HP/UX needs
  * libtool.m4: Custom $symcode for Tru64 UNIX to catch 'Q',
  * libtool.m4 (aix): When LDFLAGS=-Wl,-brtl,[other options],
  * libtool.m4: If ld is being used on IRIX to embed the
  * libtool.m4: When a module is built for AIX, the 'lib'
  * libltdl/ltdl.c: Init char * to NULL, not 0. And, for

Alexandre Duret-Lutz (2):
  * libtool.m4 (AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE): Honor
  * ltdl.m4 (AC_LIB_LTDL, AC_LTDL_ENABLE_INSTALL,

Assar Westerlund (1):
  * ltdl.m4 (AC_LTDL_DLLIB): call dlopen with arguments so the test

Brad Smith (1):
  * libtool.m4: $linker_flag - $compiler_flag for OpenBSD

Christoph Egger (1):
  * libtool.m4 (darwin): Add -install_name to the link line only

Daniel Kobras (1):
  * libltdl/ltdl.c (try_dlopen): Don't return bogus handle to user

Dave Vasilevsky (1):
  * ltmain.in: Remove convenience libraries from deplibs for Darwin.

Donald D. Anderson (1):
  * ltmain.in: Treat freebsd like openbsd, in that -lc/-lc_r should

Fritz Elfert (1):
  * libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS): Modify archive_expsym_cmds

Gary V. Vaughan (19):
  * configure.in: Bumped version to 1.4.2a.
  * bootstrap: Be robust to having no files that need removing.
  * libltdl/Makefile.am (OBJECTS):  In addition to making $(OBJECTS)
  * ltmain.in (exec_cmd): Don't overquote or we end up with this:
  typo
  * libltdl/ltdl.c: Added support for dmalloc, and uncovered some
  * libtool.m4 (archive_cmds) [darwin1.[0-2]]: Darwin uses zsh-3.1.6
  From Tor Lillqvist [EMAIL PROTECTED]:
  * libtool.m4 (AC_LIBLTDL_CONVENIENCE): s/INCLTDL/LTDLINCL/ for
  * ltdl.m4 (AC_WITH_LTDL): New macro to add `--with-included-ltdl'
  From Tom Bates  [EMAIL PROTECTED]:
  From Joseph S. Myers  [EMAIL PROTECTED]
  Revert last change -- LTCC is not used in this branch
  * libtoolize.in: The test for whether AC_PROG_LIBTOOL is defined
  * TODO: Removed obsolete comments about RMS' package system.
  From Kevin Ryde  [EMAIL PROTECTED]:
  * libltdl/ltdl.c (foreach_dirinpath): Ensure that filename is '0'
  * libltdl/ltdl.c (argz_insert): Actually, BEFORE can be NULL
  * libtool.m4 (sys_lib_search_path_spec):  Remove extraneous '='

Guido Draheim (2):
  * ltmain.in: Display better and different error messages when
  * ltdl.m4: Changed underscode to underscore.

Jean-Frederic Clere (1):
  * libtool.m4: Update support for Fujistu-Siemens Computers (FSC).

Mo DeJong (1):
  * ltmain.in: Place parens around a generated relink_command

Ossama Othman (1):
  From Roger Leigh [EMAIL PROTECTED]:

Paul Eggert (2):
  * ltmain.in: Don't assume that sort +2 works, as POSIX
  * libtool.m4 (_LT_AC_LTCONFIG_HACK): head -1 - sed 1q to

Rainer Orth (2):
  * ltmain.in (irix, nonstopux): Set major before use.
  * libtool.m4 (osf[345]): Append $major to soname_spec.

Robert Boehne (4):
  With help from Michael Matz [EMAIL PROTECTED]:
  * libtool.m4 (AC_DEPLIBS_CHECK_METHOD): Add mips/mipsel to list of
  * libtool.m4 (LT_AC_PROG_SED): New macro tests sed for truncation of
  GNU libtool 1.4.3 was released.

Volker Christian (1):
  * libltdl/ltdl.c (find_handle_callback): treat the result of a call

---


hooks/post-receive
--
GNU Libtool


___
Libtool-commit mailing list
Libtool-commit@gnu.org
http://lists.gnu.org/mailman/listinfo/libtool-commit

Re: libtool support for intel icc compiler

[Robert Boehne]

icc users:

Aparently support for icc isn't complete.  Here is where
you can help by submitting a patch that fixes the problems
you're running into.  I don't have access to this compiler,
so if it is something you want, you'll have to volunteer to
do it.  Please read http://www.gnu.org/software/libtool/contribute.html
before you post your patch.

Thanks,

Robert

Himanshu_Khurana wrote:
 
 Hi all
 I have been struggling with this since quite a while now. This is what I have found. 
 Some changes in libtool.m4 have been made to support Intel compiler.Thes are like
 ..
 ..
 icpc)
   # Intel C++
   _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
   _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
   _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
 ..
 ..
 linux*)
   case $cc_basename in
   icc|ecc)
 _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
 ;;
 ..
 ..
 
 WHICH means that libtool must now supoort both icc and icpc . BUT when I am running 
 my configure script by setting the following environment variables
 
 CC=icc
 CXX=icpc
 LD=ld
 
 PATH and LD_LIBRARY_PATH accordingly set to find the above
 
 IT SEEMS that the above mentioned changes in libtool.m4 are never incorporated in my 
 case. Either this is a bug or may be I am making a blunder .Of these two options  
 latter is a strong possibility  because its just been 10 days since I have started 
 with linux . :-)
 
 Coming back to the point
 I run
 ./bootstrap DOESNT COMPLAIN WITH ANY ERRORS
 ./configure --prefix=/home/me/usrDOESNT COMPLAIN WITH ANY ERRORS
 makeGIVES THE FOLLOWING ERROR
 
 ...
 ...
 configure: creating ./config.status
 /bin/sh ./libtool --mode=compile icc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o lt
 dl.lo `test -f 'ltdl.c' || echo './'`ltdl.c
 mkdir .libs
  icc -DHAVE_CONFIG_H -I. -I. -I. -g -c ltdl.c  -DPIC -o .libs/ltdl.o
  icc -DHAVE_CONFIG_H -I. -I. -I. -g -c ltdl.c -o ltdl.o /dev/null 21
 /bin/sh ./libtool --mode=link icc  -g   -o libltdl.la -rpath /home/himanshu/usr/
 /lib -no-undefined -version-info 4:0:1 ltdl.lo -ldl
 icc -shared  .libs/ltdl.o  -ldl -lc  -soname libltdl.so.3 -o .libs/libltdl.so.3.
 1.0
 icc: Command line warning: ignoring unknown option '-soname'
 ld: cannot open libltdl.so.3: No such file or directory
 make[2]: *** [libltdl.la] Error 1
 make[2]: Target `all-am' not remade because of errors.
 make[1]: *** [all] Error 2
 make: *** [all-recursive] Error 1
 make: Target `all' not remade because of errors.
 
 WHEN I SAY
 ls
 
 I CAN SEE libtool having already been made
 
 AND WHEN I SAY
 
 ./libtool --config
 
 I GET
 
 ..
 ..
 # Libtool was configured on host blrkecxxx:
 
 # Shell to use when invoking shell scripts.
 SHELL=/bin/sh
 
 # Whether or not to build shared libraries.
 build_libtool_libs=yes
 
 # Whether or not to build static libraries.
 build_old_libs=yes
 
 # Whether or not to add -lc for building shared libraries.
 build_libtool_need_lc=yes
 
 # A C compiler.
 LTCC=icc
 
 # A language-specific compiler.
 CC=icc
 
 # Is the compiler the GNU C compiler?
 with_gcc=
 # The linker used to build libraries.
 LD=ld
 
 # How to pass a linker flag through the compiler.
 wl=
 
 # Additional compiler flags for building library objects.
 pic_flag= -DPIC
 pic_mode=default
 
 ..
 ..
 
 NOW WHAT I THINK IS THAT SINCE LIBTOOL FOR ICC IS NOT BEING TAUGHT HOW TO handle 
 PIC,and linker flag(wl=Wl,) and this is why the make command is  failing due to 
 inability of icc to pass -soname option to linker.
 
 WHICH MEANS that the abovementioned piece of code-patch in libtool.m4 is not being 
 accessed.
 
 MY QUESTION IS WHY? IS IT A PROBLEM WITH THW WAY I AM DOING THINGS ???
 LOOKING FOR HELP
 
 :-)
 Himanshu Khurana
 Software Engineer
 Infosys Technologies,Bangalore,India
 
 -Original Message-
 From: Roberto Bagnara [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, March 25, 2003 12:40 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; Himanshu_Khurana
 Subject: Re: libtool support for intel icc compiler
 
 Robert Boehne wrote:
   You can always get the latest CVS version of GNU Libtool at:
   ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
  
   It does contain support for icc.
 
 No, support for icc is broken, the problem has been reported
 to no avail, and the email address of the person who did the
 icc port bounces.  See
 http://mail.gnu.org/archive/html/libtool/2003-03/msg0.html
 for more information (same problem with the current HEAD).
 Cheers
 
  Roberto
 
 --
 Prof. Roberto Bagnara
 Computer Science Group
 Department of Mathematics, University of Parma, Italy
 http://www.cs.unipr.it/~bagnara/
 mailto:[EMAIL PROTECTED]


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Q] Simple dlopen test program

[Robert Boehne]

Zaufi,

I think you misunderstand how this is intended to work, for most
uses, Libtool can provide a portable interface to dlopen or some
similar system function with libltdl.  Your project isn't using
libltdl, instructions on how to use it are in the manual.

HTH,

Robert

zaufi wrote:
 
 Hi!
 
 I update libtool from CVS 30 min ago, and wrote simple test project (see
 attached .tar.bz2) which is use `dlopen' to load shared library.
 The problem I found is that there is now way (at least I don't know it) to
 determinate name of library where dlopen was found... so this test program
 fail to link. As I remember (fix me if I'm wrong) in some previous version of
 libtool -ldl was stored in substed LIBADD_DL  variable after ./configure, but
 in CVS version I can't found this :((
 
 How to make my test project compilable???
 
 P.S.: Why even after determinate that F77 is not needed,
 
 checking whether we are using the GNU Fortran 77 compiler... no
 
 libtool doing the following (moreover doing incorrectly as I can see)???
 
 ...snip...
 appending configuration tag F77 to libtool
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking for  option to produce PIC... -fPIC
 checking if  PIC flag -fPIC works... no
 checking if  supports -c -o file.o... no
 checking whether the  linker (/usr/bin/ld) supports shared libraries... yes
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking dynamic linker characteristics... ./configure: line 1:
 -print-search-dirs: command not found
 GNU/Linux ld.so
 configure: creating ./config.status
 ...snip...
 
 Regards.
 Alexander
 
   
Name: libtool-test.tar.bz2
libtool-test.tar.bz2Type: application/x-tbz
Encoding: base64
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: When is 1.5 due for release?

[Robert Boehne]

Nick,

Before April 15 (2003).

Robert

Nick Hudson wrote:
 
 Subject says it all.
 
 Thanks,
 Nick
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Convenience Libraries

[Robert Boehne]

Bill Northcott wrote:
 
  In general, Libtool won't prevent you from doing anything
  that the linker can.  This works by passing flags through
  Libtool with these flags:
 
 Not really.  As has been discussed here before it will not let you produce
 a dynamic by linking static libraries, although this can be done with
 direct invocation of gcc or ld on MacOS X.

Bill,

I don't think you're correct about this.  I think if you were to
change this:
libtool --mode=link -rpath /usr/local -o libfoo.la foo.lo
/usr/local/lib/libstatic.a
to:
libtool --mode=link -rpath /usr/local -o libfoo.la foo.lo
-Wl,/usr/local/lib/libstatic.a
then Libtool would totally ignore libstatic.a and pass it on to the
linker.

 
  And another spot where convenience libraries are discussed:
 
 Unfortunately that is the one and only spot where they are discussed and
 it does not say much.
 
 Perhaps it would help, if I clarify what we are trying to do.
 
 The Swarm project has a hierarchy of three levels of libraries:
 Basics like BLT, and libobjc
 Swarm modules which are subsets of the API.  These reference symbols in
 the basics and also each other.
 A swarm library which is the top of the hierarchy and uses symbols from
 all of the above.
 
 Libtool appears to restrict options to an either or choice:
 Either: Build everything static in which case every symbol will be
 incorporated into every executable built against the top level library.
 OR: Build everything dynamic in which case everything has to be in the
 right place at the right times and a complex DYLD_LIBRARY_PATH set up to
 get the apps to run.  and you also get plagued with run time warning about
 not being able to find the build directories.  Might this last problem go
 away with --disable-fast-install?
 
 What we would like to do is to build most of the lower level libraries
 static and link them into a single swarm dynamic library against which
 executables would be dynamically linked.  Libtool; appears to specifically
 rule this out.
 
 Or can you explain how to do it?

In this case you would want to change the lower level libraries to
convenience libraries.  When Libtool then attempts to link the swarm
dynamic library, it would simply incorporate the ojbect files into
the dynamic library.  It's common practice to organize software by
bundling it up in archives, convenience libraries simply allow you to
do this portably.  If the user configures to build all-static, then
it will do the same, i.e. archive the same object files (swarm's + any
convenience lib's objects) into the swarm static archive.
If you're using Automake, use noinst_LTLIBRARIES to define which
libs are convenience libs.

HTH,

Robert


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: cvs/HEAD: broken clean on linux+libtool

[Robert Boehne]

Wesley,

IMHO, Libtool is better off if you change your clean rule to:

clean:
(cd main  libtool --mode=clean rm -f test test.o)
(cd lib2  libtool --mode=clean rm -f libb.la b.lo)
(cd lib1  libtool --mode=clean rm -f liba.la a.lo)

HTH,

Robert

Wesley W. Terpstra wrote:
 
 I have attached a small example tar.gz of this (obvious) bug.
 
 cd test
 make
 make clean
 
 ... and it is not that clean. (it leaves .la and .a files in */.libs)
 
 If you look at the commands libtool executes:
 
 rm -f lib2/libb.la lib2/main/main/.libs/libb.al
 lib2/main/main/.libs/libb.la lib2/main/main/.libs/libb.lai
 
 rm -f lib1/liba.la lib1/lib2/lib2/main/main/.libs/liba.al
 lib1/lib2/lib2/main/main/.libs/liba.la
 lib1/lib2/lib2/main/main/.libs/liba.lai
 
 ... you will see that it is definitely on crack.
 
 There is simply something wrong in the directory logic.
 I presume this is broken on all architectures.
 
 Please fix before 1.5. :-)
 
 Thanks.
 
 PS. I am hoping this attached test makes the bug more clear since my
 previous *4* posts (one of which was a work-around patch) on this bug have
 been silently ignored.
 
 ... I am also interested if someone can test the 'make' part on MacOS.
 I have heard rumours that this fails.
 
 --
 Wesley W. Terpstra [EMAIL PROTECTED]
 
   
Name: test.tgz
test.tgzType: GNU Tape Archive (application/x-gtar)
Encoding: base64
 
Part 1.1.2Type: application/pgp-signature
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool Digest, Vol 3, Issue 35

[Robert Boehne]

Bill,

In general, Libtool won't prevent you from doing anything
that the linker can.  This works by passing flags through
Libtool with these flags:

`-Wl,FLAG'
`-Xlinker FLAG'
 Pass a linker specific flag directly to the linker.

`-XCClinker FLAG'
 Pass a link specific flag to the compiler driver (CC) during
 linking.

And another spot where convenience libraries are discussed:

Linking static libraries


   Why return to `ar' and `ranlib' silliness when you've had a taste of
libtool?  Well, sometimes it is desirable to create a static archive
that can never be shared.  The most frequent case is when you have a
set of object files that you use to build several different programs.
You can create a convenience library out of those objects, and link
programs with the library, instead of listing all object files for
every program.  This technique is often used to overcome GNU automake's
lack of support for linking object files built from sources in other
directories, because it supports linking with libraries from other
directories.  This limitation applies to GNU automake up to release
1.4; newer releases should support sources in other directories.

   If you just want to link this convenience library into programs, then
you could just ignore libtool entirely, and use the old `ar' and
`ranlib' commands (or the corresponding GNU automake `_LIBRARIES'
rules).  You can even install a convenience library (but you probably
don't want to) using libtool:

 burger$ libtool --mode=install ./install-sh -c libhello.a
/local/lib/libhello.a
 ./install-sh -c libhello.a /local/lib/libhello.a
 ranlib /local/lib/libhello.a
 burger$

   Using libtool for static library installation protects your library
from being accidentally stripped (if the installer used the `-s' flag),
as well as automatically running the correct `ranlib' command.

   But libtool libraries are more than just collections of object files:
they can also carry library dependency information, which old archives
do not.  If you want to create a libtool static convenience library, you
can omit the `-rpath' flag and use `-static' to indicate that you're
only interested in a static library.  When you link a program with such
a library, libtool will actually link all object files and dependency
libraries into the program.

   If you omit both `-rpath' and `-static', libtool will create a
convenience library that can be used to create other libtool libraries,
even shared ones.  Just like in the static case, the library behaves as
an alias to a set of object files and dependency libraries, but in this
case the object files are suitable for inclusion in shared libraries.
But be careful not to link a single convenience library, directly or
indirectly, into a single program or library, otherwise you may get
errors about symbol redefinitions.

   When GNU automake is used, you should use `noinst_LTLIBRARIES'
instead of `lib_LTLIBRARIES' for convenience libraries, so that the
`-rpath' option is not passed when they are linked.

   As a rule of thumb, link a libtool convenience library into at most
one libtool library, and never into a program, and link libtool static
convenience libraries only into programs, and only if you need to carry
library dependency information to the user of the static convenience
library.

   Another common situation where static linking is desirable is in
creating a standalone binary.  Use libtool to do the linking and add the
`-all-static' flag.



Bill Northcott wrote:
 
 A convenience library is usually part of your own package,
 it turns into a list of object files when you link to it.
 It could be in a subdirectory, much like libltdl is for
 many packages that use it.
 Here is a section of the manual that mentions them:
 http://www.gnu.org/software/libtool/manual.html#SEC14
 
 Unfortunately all it does do is mention them!  It does not explain what it
 means or how to build or use them.  Is there any useful documentation?
 
 What we are looking for on MacOS X is the ability to link a static library
 into a dylib with the -all-load flag, which ensures all symbols are loaded
 even if not referenced.  Having read the MacOS X ld docs, this is the only
 way to build a dylib which actually includes all the symbol definitions
 from some other library.
 I seem to remember seeing libtool use the -all-load flag, but I spent
 several hours reading what documentation there is and I can see no clues
 how to do this.
 
 Bill Northcott
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: relinking broken on macosx?

[Robert Boehne]

Approved  checking in to CVS head.

Thanks,

Robert

Benjamin Reed wrote:
 
 On Tuesday, February 25, 2003, at 10:30 PM, Peter O'Gorman wrote:
 
  Ben,
  I have a patch to disable relinking, for some reason on current
  libtool,
  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
  This is wrong, and makes libtool think relinking is required, set it
  to no.
  I am not sure if you also need to set
  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
  I haven't looked in ltmain, it may need this var to be set to actually
  disable relinking, as you can see doing this is pretty meaningless.
 
 Yup, this works for me -- libtool 1.5 now properly builds arts and
 other KDE stuff on KDE-Darwin without any patches.
 Attached is the patch against current CVS...  (OK, so one patch, but
 I'm working under the assumption this will be accepted =)
 
 Thanks for the help, everyone, libtool 1.5 is looking pretty solid now
 on OSX.
 
   
   Name: libtool-darwin-hardcode-fixes.patch
libtool-darwin-hardcode-fixes.patchType: unspecified type 
 (application/octet-stream)
   Encoding: 7bit
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MacOSX module linking with static archive libtool problem

[Robert Boehne]

Brad,

A convenience library is usually part of your own package,
it turns into a list of object files when you link to it.
It could be in a subdirectory, much like libltdl is for
many packages that use it.
Here is a section of the manual that mentions them:
http://www.gnu.org/software/libtool/manual.html#SEC14

Even when the archive contains only PIC, there are sometimes
extra flags that have to be passed, like -full_archive (IIRC)
to get all of the object files into the target.  That means
if you depend on using some part of an archive you're linking
against that isn't used by the object files you're linking into
the shared lib, those symbols won't appear in your shared library.
Some linkers will link all the archive's objects, some won't,
and you won't find out until your software is in the field.
That's bad.
In the list of platforms you give below, I think that HPUX is
probably the most picky about PIC objects.  I had a hell of a time
once when Autoconf would find a static version of a system library
(and therefore add it in) but it wasn't PIC, and my shared library
builds died when it tried to link it.
If your archive is built by someone else, you won't know if it
is PIC or not, unless you happen to be on a platform where
that's all there is.
If OpenSSL is designed to be static only, then it probably should
be linked only to executables.  There may be some security advantages
to NOT having OpenSSL code in a shared lib, and by making one you
may open up a vulnerabiltiy.
  In the end, we can't support linking archives into shared libs
because it isn't portable.  This has been discussed before on this
list, so perhaps my predecessors were a bit more elegant in presenting
their arguments.  You may want to search the archives for past
discussions on this topic.

Thanks,

Robert Boehne


Brad House wrote:
 
 Does a convenience library have to be part of your own
 package? I've looked through the libtool manual and
 cannot find anything about convenience libraries, a pointer
 to a reference would be greatly appreciated.
 
 If it must be part of your own build, it would be nearly
 impossible to convert all of OpenSSL over to use
 autoconf/automake/libtool, just so I could statically
 link it into another shared object (Especially on
 OS X as there's no telling when Apple is going to
 release a fix for the latest openssl vulnerability,
 or go to the openssl 0.9.7a series so that we
 can take advantage of AES or eliptic curve algoths)
 
 Anyhow, the way we currently do it (linking against
 static libraries to create a module/shared lib), works
 on:
 
 Linux (ppc, x86) [need to test alpha  sparc, but I have
the hw to do so]
 FreeBSD (x86)
 SCO (OpenServer5  Unixware7)
 AIX (4.3.3) [have not tested on 5.x yet]
 Solaris (sparc  x86)
 OpenBSD (x86)
 
 The only remaining major platforms that I have not
 tested on are Tru64 (which is Alpha, and you said
 PIC doesn't matter there), Irix, and
 HP-UX (PA-RISC  ia64)
 
 What happens if these platforms prove to be immune
 to this as well.  Why would it not be a good thing
 to do?  Perhaps I'm naive, but seems like maybe
 this is a deprecated concern?
 
 Anyhow, the real point is that IT DOES WORK if you
 link by hand, but LibTool doesn't support it.  And
 those other platforms that it does work on (which is
 all in my exp), LibTool also works on, therefore it
 is a divergence from behavior of the other platforms.
 Though it might not be the good thing to do, I'm
 more concerned with what works in practice, as
 in theory isn't always the best thing to implement.
 
 -Brad
 
 Robert Boehne wrote:
  Brad,
 
  You are correct that all PPC code is pic, so is Alpha.
  Still, that doesn't mean that this behavior is portable,
  nor does it mean that building a shared lib from a
  static archive is a good thing to do.  Your software will
  be better off if it does not depend on archive libraries
  being PIC, and from your end this is easy to work around
  by using convenience libraries.  If Libtool allowed this
  then you would have never learned why you shouldn't do it.
  That is precisely why it operates this way.
  If I recall correctly, you build a convenience library by
  not specifying -static nor -rpath on Libtool's link line.
  Automake also has support for convenience libraries built in.
 
  HTH,
 
  Robert
 
  Brad House wrote:
 
 Ok, I've put some thought into this over the weekend,
 and I think it should be classified as a BUG.  The
 argument you put up about library compiled as PIC
 is irrelevant on PPC.  Here's a snippet from the
 libtool manual:
 (http://www.gnu.org/software/libtool/manual.html#FOOT11)
 
 All code compiled for the PowerPC and RS/6000 chips (powerpc-*-*,
 powerpcle-*-*, and rs6000-*-*) is position-independent, regardless of
 the operating system or compiler suite. So, regular objects can be
 used to build shared libraries on these systems and no special PIC
 compiler flags are required.
 
 And MACOSX is PPC!
 We have this same

Re: Update for icc

[Robert Boehne]

Ok, looks reasonable to me, Approved with this
ChangLog entry:
2003-02-17  Allan Sandfeld Jensen  [EMAIL PROTECTED]

* libtool.m4: Intel icc fixups for version 7.0.

Thanks!

Robert

Allan Sandfeld Jensen wrote:
 
 Hi Robert
 
 Here's an update on my icc-patch
 
 I have checked how my patch works from CVS HEAD now against icc 7.0. It
 finally seems Intel with version 7.0 has made a usefull standard C++ library.
 I have even be able to compile at full working KDE-suite.
 
 Libtool CVS just need to following additional patch to compile KDE, it does 2
 things:
 1. Change ld-option flag from Qoption ld to GNU syntax -Wl. This is because
 the first form does not expand inline, and that's needed for --whole-archive.
 (icc 5.0 does not support -Wl, but since it doesnt compile libltdl anyway I
 consider it unsupported)
 2. I have removed the -nostdlib option, since this prevents icpc from linking
 with it's own C++ library (libcxa and libunwind)
 
 Patch attached.
 
 Greetings
 `Allan
 
   
   Name: icc-patch2.diff
icc-patch2.diffType: text/x-diff
   Encoding: 7bit
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Migrating existing libraries to libtool

[Robert Boehne]

Keith,

Tough problem you've got here, I don't really see a way
around it without a new versioning flag other than
creating a libX??.la file for the last version of a library
you're attempting to install (which may or may not work anyway).
I would say that a patch to add this flag should warn the user
that this flag is only for situations like yours, where some
other versioning scheme must be supported for legacy reasons.
Documentation would also need to reflect this.  We wouldn't
want new users to abuse this flag because the don't understand
what Libtool is doing.
Send in the patch soon, and it could be in the 1.5 release.

Thanks,

Robert


Keith Packard wrote:
 
 Around 2 o'clock on Feb 18, Simon Richter wrote:
 
  To remain binary compatible, it suffices to have the same major version,
  as programs are expected to link against the .so.major file. Which
  file this actually symlinks to is irrelevant. So in fact you start off
  using -version-info major:0:0 and then go on as in the libtool
  manual.
 
 No, that will give minor version 0 which would be seen as *older* than the
 previous version of the library.  I really need major and minor versions
 to match so I can build replacement versions with the new tools that match
 precisely with what's already installed.
 
  Hrm, how is that solved currently with imake?
 
 Imake has all of the necessary system-dependent mechanisms to generate
 correct link commands given the desired major and minor version numbers.
 It doesn't modify the version numbers provided, it simply uses whatever
 pieces are appropriate and ignores the low order values.  This has worked
 for some time now and developers have become comfortable with the
 kind of version checking and compatibility issues related to the set of
 platforms this is deployed on.
 
 I've tried to use automake for existing X libraries and eventually had to
 give up and fall back to autoconf as libtool was unable to preserve the
 correct major and minor versions on even Linux and BSD.  I'd rather not be
 forced to support yet another krufty set of build kludges for X just
 because libtool has different ideas on library versioning schemes than
 we've been using for X.  automake is so close to working, let's close the
 gap and let imake die a well deserved death (with apologies to Todd
 Brunhoff)
 
 -keith
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Pending release of 1.5

[Robert Boehne]

Bill Northcott wrote:
SNIP
 
  Aside from the obvious problem of linking a shared library
  to a static archive, which is not portable, I think this
  is the source of your problem.
 
 I may be being dense, but I thought the point of libtool was to do things
 differently on different platforms.  The code concerned builds happily on
 a wide range of other UNIXen (Solaris, Linux x86 and PPC, Tru64, AIX
 etc..)  and Cygwin.

If a compiler does not generate PIC code by default then Libtool creates
archive files from non-pic code.  I think hppa/HPUX might have a problem
with this for instance.

 My real concern was the apparent regression from 1.4.3 to the current
 libtool code.

Yes, this concerns me too, I'm pretty sure all the patches in 1.4.3 went
into CVS head, so it might be a feature added later on. (!)

 Can you tell us what happens
  in Libtool that causes this?  i.e. run the same command with
  /bin/sh -x ../../libtool and pipe the output to a file.
 
 I will try to do this for both cases and send you the files.  I will
 include another point in the source code where all versions of libtool
 fail to link.
 
 Bill Northcott

I think this is the only way to get down to it, hopefully they won't be
too long.  It may be necessary for you to inspect the output a bit
and trim out what is obviously not necessary.

Thanks,

Robert


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Pending release of 1.5

[Robert Boehne]

Ralph,

Yes, that would be fine.

Robert

Schleicher Ralph (LLI) wrote:
 
 Robert Boehne wrote:
 
  I'm just about to make the release of Libtool 1.5.  If anyone would
  like to test the current CVS on their favorite platform and report
  any problems, please do so!  If not, your woes may have to wait for
  1.5.1.
 
 The new option -shrext implies a leading dot for the shared library
 suffix.  This is IMHO sub-optimal because it does not permit the user
 to generate modules with no shared library suffix at all.  GPG, for
 example, builds modules with no shared library suffix.
 
 My original patch required to explicitly add a dot.  Do you accept a
 patch that restores the original behavior?
 
 --
 Ralph
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Pending release of 1.5

[Robert Boehne]

Bill,

I notice in the problem link line, the shared libdefobj.4.dylib is
linked to ../../avcall/.libs/libavcall.a twice.
Aside from the obvious problem of linking a shared library
to a static archive, which is not portable, I think this
is the source of your problem.  Can you tell us what happens
in Libtool that causes this?  i.e. run the same command with
/bin/sh -x ../../libtool and pipe the output to a file.

HTH,

Robert

Bill Northcott wrote:
 
  I'm just about to make the release of Libtool 1.5.  If anyone would
  like to test the current CVS on their favorite platform and report
  any problems, please do so!  If not, your woes may have to wait for
  1.5.1.
 
 We are trying to build a complex libtoolised package (Swarm) on MacOSX.
 
 The libtool command is:
 /bin/sh ../../libtool --mode=link /Users/billn/Public/GNU/dst/bin/gcc  -g
 -O2 -fgnu-runtime -fno-strict-aliasing -Wall -Wno-import -Wno-protocol
 -Wno-long-long -Wno-unknown-pragmas -Wno-unknown-pragmas   -o libdefobj.la
  -rpath /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib
 -version-info 4:0:0 Archiver.lo LispArchiver.lo HDF5Archiver.lo
 Arguments.lo Create.lo Customize.lo DefClass.lo DefObject.lo HDF5Object.lo
 Program.lo Symbol.lo Zone.lo FCall.lo FArguments.lo defobj.lo internal.lo
 java.lo directory.lo JavaProxy.lo JavaClassProxy.lo JavaCollection.lo
 JavaCollectionIndex.lo COMProxy.lo fcall_objc.lo fcall_java.lo COM.lo
 modulemap.lo ../../avcall/libavcall.la
 
 after much complainng this produces a link instruction:
 /Users/billn/Public/GNU/dst/bin/gcc -dynamiclib -flat_namespace -undefined
 suppress -o .libs/libdefobj.4.0.0.dylib .libs/libdefobj.la-27.o -all_load
 ../../avcall/.libs/libavcall.a  ../../avcall/.libs/libavcall.a
 -install_name
 /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib/libdefobj.4.dylib
 -compatibility_version 5 -current_version 5.0
 
 which fails with multiple definitions of symbols in libavcall.a.
 
 This was broken in 1.4.2.  Apparently fixed in the 1.4.3 release and seems
 to be broken again in 10 Feb cvs snapshot I tried yesterday.
 
 I think we give up and use jam on MacOS X until you guys think this thing
 is ported.
 
 Bill Northcott
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: CVS, bootstrapping and DJGPP

[Robert Boehne]

Richard,

It looks to me like automake isn't installed correctly.  Automake
provides macros like AM_INIT_AUTOMAKE to Autoconf, so Autoconf
needs to find them.

HTH,

Robert

Richard Dawe wrote:
 
 Hello.
 
 I've been trying to bootstrap a CVS check-out of libtool and I've hit some
 problems. The problems occur when I run the boostrap script. I'm using the
 DJGPP ports of autoconf 2.57 and automake 1.7.2.
 
 Firstly, I keep getting the following message:
 
 configure.ac: `AM_INIT_AUTOMAKE' must be used
 automake: your implementation of AM_INIT_AUTOMAKE comes from an
 automake: old Automake version.  You should recreate aclocal.m4
 automake: with aclocal and run automake again.
 automake: no `Makefile.am' found or specified
 
 So I ran aclocal and re-ran bootstrap. I got the same error message. I also
 tried changing the following in configure.ac:
 
  AM_INIT_AUTOMAKE(AC_PACKAGE_TARNAME, AC_PACKAGE_VERSION)
 
 to have no arguments, []-quoted arguments, etc., but that made no difference.
 
 Has anyone else seen this problem? If not, then it must be a problem with the
 DJGPP port of automake 1.7.2.
 
 Secondly, bootstrap doesn't seem to create any Makefile.in files. The line
 that runs automake is:
 
  eval $AUTOMAKE $AUTOMAKE_FLAGS
 
 Shouldn't there be a Makefile name after that? Also, shouldn't the script
 create Makefile.in in the top-level directory and doc directories?
 
 Thanks, regards,
 
 --
 Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Pending release of 1.5

[Robert Boehne]

Alexandre,

Snapshots of CVS are made daily and reside at
ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
I'm not sure where to announce a pending release other
than here, but I had just intended to re-release after
bugs were fixed  found in 1.5.  If you have a suggestion
on where to announce the pre-release, let us know.

Thanks,

Robert

Alexandre Duret-Lutz wrote:
 
  Robert == Robert Boehne [EMAIL PROTECTED] writes:
 
  Robert Hello,
  Robert I'm just about to make the release of Libtool 1.5.  If anyone would
  Robert like to test the current CVS on their favorite platform and report
  Robert any problems, please do so!  If not, your woes may have to wait for
  Robert 1.5.1.
 
 Great news!  How about making a test release (1.4f, say), and
 announcing it to more that just [EMAIL PROTECTED] to get wider
 testing?
 
 The last snapshot of this branch (1.4d) is one year old, and not
 everybody is able to test Libtool off CVS.
 
 Cheerio,
 --
 Alexandre Duret-Lutz


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AC_CHECK_LIB(m, main, LIBM=-lm) broken with C++ [PATCH]

[Robert Boehne]

How about this patch?
The math library is not actually used by anything but the
test suite in Libtool, so as long as the C standard and
common practice put cos in -lm it's all good.

ChangeLog entry:

2003-02-05  Robert Boehne  [EMAIL PROTECTED]

* libtool.m4 (AC_CHECK_LIBM): Search for a real symbol in
the math library rather than 'main', it causes problems for
C++ compilers with certain Auto* tools.
(AC_LIBLTDL_INSTALLABLE): ditto.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.297
diff -u -r1.297 libtool.m4
--- libtool.m4  5 Feb 2003 07:03:55 -   1.297
+++ libtool.m4  6 Feb 2003 02:50:39 -
@@ -2246,10 +2246,10 @@
   ;;
 *-ncr-sysv4.3*)
   AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM=-lmw)
-  AC_CHECK_LIB(m, main, LIBM=$LIBM -lm)
+  AC_CHECK_LIB(m, cos, LIBM=$LIBM -lm)
   ;;
 *)
-  AC_CHECK_LIB(m, main, LIBM=-lm)
+  AC_CHECK_LIB(m, cos, LIBM=-lm)
   ;;
 esac
 ])# AC_CHECK_LIBM
@@ -2294,7 +2294,7 @@
 # In the future, this macro may have to be called after
AC_PROG_LIBTOOL.
 AC_DEFUN([AC_LIBLTDL_INSTALLABLE],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
-  AC_CHECK_LIB(ltdl, main,
+  AC_CHECK_LIB(ltdl, lt_dlinit,
   [test x$enable_ltdl_install != xyes  enable_ltdl_install=no],
   [if test x$enable_ltdl_install = xno; then
  AC_MSG_WARN([libltdl not installed, but installation disabled])


Albert Chin wrote:
 
 On Wed, Feb 05, 2003 at 03:00:39PM -0600, Bob Friesenhahn wrote:
  I posted a detailed message to [EMAIL PROTECTED] and
  [EMAIL PROTECTED] but there has been no response at all so I will
  post again.
 
  CVS libtool.m4 contains lines like
 
AC_CHECK_LIB(m, main, LIBM=-lm)
 
  and
 
AC_CHECK_LIB(ltdl, main, ... blah
 
 Gross!
 
  What is the best path forward?
 
 Replace main with a *real* function in one of the libraries.
 
 --
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: linux/alpha and ccc compiler

[Robert Boehne]

Bob,

Does this patch actually work?  It looks to me like you're inheriting
gcc's
configuration and then changing one flag.  If you have not run the test
suite yet, run it and post the results.  Where did this compiler come
from?
I've been using Alphas since mips/ULTRIX went away, and I've never heard
of this compiler.  Follow the advice I gave you previously, read the
documenation
and run the test suite to see how you're going.  For comparison, CVS
Libtool
passes all 105 tests with c89, cxx and f90 on my Tru64 4.0f machine.

Robert

Bob McElrath wrote:
 
 Here is a trivial patch to add Compaq's alpha c compiler (ccc) to
 libtool.m4.  This is against CVS head.
 
 Cheers,
 Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]
 
 You measure democracy by the freedom it gives its dissidents, not the
 freedom it gives its assimilated conformists. -- Abbie Hoffman
 
   
 Name: 
libtool.m4.ccc.cvshead.20030205.patch
libtool.m4.ccc.cvshead.20030205.patchType: Plain Text (text/plain)
 Encoding: quoted-printable
 
Part 1.1.2Type: application/pgp-signature
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

OS/X Libtool -bundle

[Robert Boehne]

Hello,

I'm having problems with Mac OS/X in CVS Libtool, and I wonder
if some of you more familiar with the platform could help out.

In an older version of Libtool, a library built with -module is
linked with:
cc -flat_namespace -undefined suppress -o .libs/libdb_tcl-4.2.so *.lo
-lc -dynamiclib -install_name 
/Users/rboehne/testdb/lib/libdb_tcl-4.2.so 

Which works like I'd expect:
[dsl092-075-147:~/db-4.2.8/build_unix] rboehne% file
.libs/libdb_tcl-4.2.so 
.libs/libdb_tcl-4.2.so: Mach-O dynamically linked shared library ppc
[dsl092-075-147:~/db-4.2.8/build_unix] rboehne% ./libtool --version
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
[dsl092-075-147:~/db-4.2.8/build_unix] rboehne% man ld
[dsl092-075-147:~/db-4.2.8/build_unix] rboehne% /usr/bin/tclsh8.3
% source ../test/test.tcl
% exit


More recent (CVS) Libtool uses a two-step linking process when -module
is present on the Libtool link line, like so:
cc -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o
.libs/libdb_tcl-4.2.so-master.o  .libs/*.o  cc -bundle -flat_namespace
-undefined suppress -o .libs/libdb_tcl-4.2.so .
libs/libdb_tcl-4.2.so-master.o

But this method doesn't seem to work:
[dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% file
.libs/libdb_tcl-4.2.so
.libs/libdb_tcl-4.2.so: Mach-O bundle ppc
[dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne% ./libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1182 2003/01/29 04:57:52)

Copyright 1996, 1997, 1998, 1999, 2000, 2001
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
[dsl092-075-147:~/new-db-4.2.8/build_unix] rboehne%  /usr/bin/tclsh8.3
% source ../test/test.tcl
dyld: /usr/bin/tclsh8.3 malformed library: .libs/libdb_tcl-4.2.so (not a
Mach-O library file, bad filetype value)

% exit

It looks to me like this should work, a module should be dlopen-able,
wheras
a Libtool library not built with -module may not.  If I take out the
-module
from the link line, I get .libs/libdb_tcl-4.2.dylib and tclsh is able to
dlopen it.  Part of what really troubles me is that file doesn't
return
the same thing on the libraries.  I do notice that file gives the same
result I'm getting on all the *.so files under /usr/lib/ though.

So am I supposed to be able to dlopen() a bundle, and if not, what can
be done with it?  I'm confused.

Thanks,

Robert Boehne


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Broken exe wrapper script on OS/X

[Robert Boehne]

Bruce,

The latest stable release is 1.4.3, and I think there are OS X patches
in it that aren't in 1.4.2.  Regardless, to get it fixed it would need
to get incorported in a pending release so CVS is the most relevant
version here.

Robert

Bruce Korb wrote:
 
 Robert Boehne wrote:
 
  Bruce,
 
  So what does CVS Libtool do?
 
 Dunno.  I don't use CVS Libtool.  I use latest stable release.
 If anyone has addressed such a problem, I'll try it.  I am
 certain this had to have been tested in the past, so this is
 a regression in 1.4.2 over some prior release.  I am also
 certain this is related to the target platform, because this
 problem does not occur on other platforms (Solaris, HP/UX,
 AIX, BSD and Linux).
 
   GNU libtool) 1.4.2
  
   Here $col refers to an ugly path to a shell script wrapper
   for the columns program.  I modified it slightly by adding
   set -x just before the command invocation.  As you can see,
   there seems to be a problem with embedded white space in command
   line arguments.  The argument gets broken in two and my program
   complains.  The platform is an OS/X 10.1 (sourceforge compile farm)
  
   ==
  
   + ls -1 *.[ch] | $col -I4 --spread=1 --line-sep=' XXX'
   + columns -I4 --spread=1 --line-sep= XXX
   columns: Command line arguments not allowed
   columns - Columnize Input Text - Ver. 1.1
   USAGE:  columns [[  ]]
  
   $ ls -1 *.[ch] | $col -I4 --spread=1 --line-sep='  XXX'
   + columns -I4 --spread=1 --line-sep=' XXX'
   columns: Command line arguments not allowed[[  ]]
  
   $ ls -1 *.[ch] | $col -I4 --spread=1 --line-sep='XXX'
   + columns -I4 --spread=1 --line-sep='XXX'
   autoopts.cautoopts.hboolean.c enumeration.c numeric.c'XXX'
   options.h pgusage.c restore.c save.cstack.c'XXX'
   streqv.h  streqvcmp.c   usage.c   version.c
  
   $ echo $0
   -bash
   ~/autogen-5.5.2pre8/=Power-Macintosh-Darwin-5.5/pkg/libopts-18.6.9
   $ uname -a
   Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 
PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC
   Power Macintosh powerpc
  
    BACK ON MY DEVELOPMENT MACHINE: 
  
   $ libtool --version
   ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37)


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Pending release of 1.5

[Robert Boehne]

Approved and checking in to CVS head.

Robert

Nick Hudson wrote:
 
 On Tuesday 04 February 2003 7:10 am, Robert Boehne wrote:
  Hello,
 
  I'm just about to make the release of Libtool 1.5.  If anyone would
  like to test the current CVS on their favorite platform and report
  any problems, please do so!  If not, your woes may have to wait for
  1.5.1.
 
 OK, here's the patch and ChangeLog entry
 
 Nick
 
   
   Name: libtool.m4.diff
libtool.m4.diffType: text/x-diff
   Encoding: 7bit
 
  Name: ChangeLog.diff
ChangeLog.diffType: text/x-diff
  Encoding: 7bit
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: XLF Compiler on powerpc-ibm-aix5.1.0.0

[Robert Boehne]

Bill,

This is fixed in CVS Libtool.

HTH,

Robert

Bill Wendling wrote:
 
 Hi all,
 
 When I use the xlf compiler (Fortran 9x) on powerpc-ibm-aix5.1.0.0,
 libtool puts the -DPIC flag in the compile line. However, the compiler
 can't handle this flag. Is there a way to stop libtool from doing this
 other than using the -static flag?
 
 Thanks!
 
 --
 || Bill WendlingReal Programmers have a Snoopy Calendar
 || [EMAIL PROTECTED]of '69 hanging on their wall
 || Coding Simian   -- Toon Moene
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: To sed or not to sed

[Robert Boehne]

Lars,

You're in luck!  CVS Libtool goes to great pains to ensure that
the sed used by it is the best one available.  It also has piecewise
linking support, most of this added by me for AutoOpenCascade
@sourceforge.
This doesn't solve the problem completely, it can't work around it
if the only sed available truncates to 2401 character lines.  It will
however pick /usr/ccs/bin/sed over /bin/sed on Solaris for example,
because
it won't truncate as much.

HTH,

Robert

Lars Hecking wrote:
 
  I came across something really annoying recently that I would not consider
  a libtool bug, but I figured the folks here are most qualified to suggest
  a solution.
 
  The problem is php 4.3.0. They have rearranged their build system for
  better portability, and stopped using convenience libraries for the
  various subdirectory builds. The consequence is that all objects are
  passed to libtool on the command line - which can be a very long list,
  depending on which features one compiles into php.
 
  On Solaris 7/8, this list of objects is too long for the native sed,
  and linking fails (some error messages about line too long). I reported
  this as a bug and was told to use GNU sed instead.
 
  Am I the only one who things that software should be buildable with
  native standard tools?
 
  The fix for me is to edit the libtool script included with php, and add
  an explicit PATH which includes GNU tools first (I don't want this change
  in my build environment, so I change it only where needed). And this needs
  to be done every time I build php :-/
 
  Generally requiring GNU sed in libtool does not work in the same way as e.g.
  in autoconf, because the requirement would affect all users of libtool, not
  only those who build and install it. A possible partial solution could be
  that libtool has a section near the top where all standard tools it uses
  are declared, e.g.
 
  Sed=/usr/bin/sed
 
  which would at least make it easier to identify and change such components.
 
  I guess it's probably not possible to get rid of sed completely (other than
  replacing it with perl, which probably nobody wants). Any other ideas?
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: flat namespaces redux

[Robert Boehne]

Albert,

Ok, I'd agree with that mostly, but in the case of AIX, Libtool
doesn't build a single archive with both shared and static, it
does the same thing it does on other platforms.  In the same
way it wouldn't be of much use if Libtool did do this, but perhaps
some AIX diehards would like it.
If there was a patch posted that worked similar to the AIX -brtl trigger
to allow for twolevel namespaces, and it didn't change default
behavior, I would consider it.  Still, regardless of how it is done,
all that twolevel namespace support will do is allow severely
broken libraries to build on a single platform.  Rather than fix
them to work with a flat namespace, like every other platform.
I liken this to encouraging bad behavior, but if someone cares
to make and test a patch that checked for LDFLAGS containing
-twolevl (or whatever the link flag is) I'd be willing to approve
it if done properly.  Even so, isn't it nearly pointless?
For this feature to really be useful a library would have to be
  a) Initially developed on OS/X
  b) dependent on two level namespace
  c) not really useful on any other plaform (no reason to
 fix for a flat namespace)
I don't think there are too many libraries that would fit this
criteria, but please, correct me if I'm wrong.

In short, I'm not dead set against the idea, I just don't see the point.

Robert


Albert Chin wrote:
 
 On Mon, Feb 03, 2003 at 11:59:03PM -0600, Robert Boehne wrote:
  Maybe I don't understand OS X, but as I see it, any library
  that needs a two level namespace would not build on any other OS
  because OS X is the only OS that supports this feature.
  Now, if that is the case, it doesn't make any sense for Libtool
  (a tool for portable library creation  use) to support a feature
  that is only present on a single platform.  Does that make sense?
 
 I think we should support the two-level namespace, even if it is
 OSX-specific. I look at libtool more as a way to easily build shared
 libraries across multiple platforms.
 
 Think about AIX. An AIX shared library (non-brtl) can contain *both* a
 static and shared member. We don't emulate this across all platforms.
 
 And, how about this warning in ltmain.in (a non-portable feature):
   echo *** Warning: Linking the shared library $output against the
   echo *** static library $deplib is not portable!
   deplibs=$deplib $deplibs
 
 --
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: flat namespaces redux

[Robert Boehne]

Albert,

Well, I'm not sure about what Apple recommends, I think
the two level namespace linker is the result of the ld team
at Apple being too low in the food chain.  ;)
If there were a good reason (like this one) that would
change the picture.  Part of the problem is that OS X is
quite odd, and I don't have one on my desk to poke at
or read docs for.  Because of that, I'm not really sure what
to do with it in many respects.

Robert

Albert Chin wrote:
 
 On Tue, Feb 04, 2003 at 09:56:47PM -0600, Robert Boehne wrote:
  [snip snip]
 
  For this feature to really be useful a library would have to be
a) Initially developed on OS/X
b) dependent on two level namespace
c) not really useful on any other plaform (no reason to
   fix for a flat namespace)
  I don't think there are too many libraries that would fit this
  criteria, but please, correct me if I'm wrong.
 
  In short, I'm not dead set against the idea, I just don't see the point.
 
 I have no clue when it comes to OSX. However, the only reason I
 support this is the impression I get that two-level namespaces are
 good for OSX. Is this true? Does Apple *recommend* flat or two-level
 namespaces?
 
 --
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: linux/alpha and ccc compiler

[Robert Boehne]

Bob,

This patch isn't quite up to par.  For one, it is against a very old
version of Libtool, and the method it uses is very sloppy.  Generally
we check the compiler by it's name, when that isn't useful we check
what -V or --version returns, and as a last resort use pre-defined
preprocessor macros.  These tests would generally be nested in the
OS case that is appropriate for the compiler so that tests aren't
conducted
unnecessarily.  The other problem with the patch is that you say you
aren't the original author.  Without the name of the original author
we can't check for copyright assignments.  Lastly, the patch sets so few
flags that I doubt it really works.
  Now, it wouldn't be too difficult for you to start from scratch with
CVS Libtool and make a patch to support this compiler.  First step is
to read the Libtool documentation that referrs to porting to new
compilers,
then have a look at how it is currently done in Libtool.  I would
suggest
looking at the stanzas for Intel's icc, your Compaq C patch would likely
go in the same place (above or below the icc code), test for ccc, and
set the same variables.  Feel free to contact me off the list if you
need
help.

Thanks,

Robert


Bob McElrath wrote:
 
 libtool does not currently recognize the Compaq C Compiler on
 linux/alpha.  Specifically, it does not recognize that it can generate
 PIC code and therefore shared libraries.
 
 Attached is a patch against libtool.m4 which should allow this to work.
 This is adapted from a patch I found on the web from 1999 (!).  Is there
 any problem with including this with future libtool distributions?
 
 Cheers,
 Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]
 
 You measure democracy by the freedom it gives its dissidents, not the
 freedom it gives its assimilated conformists. -- Abbie Hoffman
 
   
 Name: libtool.m4.20030204.ccc.patch
libtool.m4.20030204.ccc.patchType: Plain Text (text/plain)
 Encoding: quoted-printable
 
Part 1.1.2Type: application/pgp-signature
 
   
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Broken exe wrapper script on OS/X

[Robert Boehne]

Bruce,

So what does CVS Libtool do?

Robert

Bruce Korb wrote:
 
 GNU libtool) 1.4.2
 
 Here $col refers to an ugly path to a shell script wrapper
 for the columns program.  I modified it slightly by adding
 set -x just before the command invocation.  As you can see,
 there seems to be a problem with embedded white space in command
 line arguments.  The argument gets broken in two and my program
 complains.  The platform is an OS/X 10.1 (sourceforge compile farm)
 
 ==
 
 + ls -1 *.[ch] | $col -I4 --spread=1 --line-sep=' XXX'
 + columns -I4 --spread=1 --line-sep= XXX
 columns: Command line arguments not allowed
 columns - Columnize Input Text - Ver. 1.1
 USAGE:  columns [[  ]]
 
 $ ls -1 *.[ch] | $col -I4 --spread=1 --line-sep='  XXX'
 + columns -I4 --spread=1 --line-sep=' XXX'
 columns: Command line arguments not allowed[[  ]]
 
 $ ls -1 *.[ch] | $col -I4 --spread=1 --line-sep='XXX'
 + columns -I4 --spread=1 --line-sep='XXX'
 autoopts.cautoopts.hboolean.c enumeration.c numeric.c'XXX'
 options.h pgusage.c restore.c save.cstack.c'XXX'
 streqv.h  streqvcmp.c   usage.c   version.c
 
 $ echo $0
 -bash
 ~/autogen-5.5.2pre8/=Power-Macintosh-Darwin-5.5/pkg/libopts-18.6.9
 $ uname -a
 Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 
2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC
 Power Macintosh powerpc
 
  BACK ON MY DEVELOPMENT MACHINE: 
 
 $ libtool --version
 ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37)
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: flat namespaces redux

[Robert Boehne]

Hello,

Maybe I don't understand OS X, but as I see it, any library
that needs a two level namespace would not build on any other OS
because OS X is the only OS that supports this feature.
Now, if that is the case, it doesn't make any sense for Libtool
(a tool for portable library creation  use) to support a feature
that is only present on a single platform.  Does that make sense?

Robert Boehne

Peter O'Gorman wrote:
 
 On Tuesday, February 4, 2003, at 12:01  AM, Benjamin Reed wrote:
 
  cc -multiply_defined suppress -prebind blah || cc -flat_namespace
  -undefined suppress blah
 
  1. libkdeui's LIBADD is -lkdecore
  2. the first half of the link complains that -lqt-mt is indirectly
  referenced
  3. it builds the library flat, and continues on
 
  when what *should* happen is it dies at #2, and we add -lqt-mt to
  libkdeui's LIBADD like it should be.
 
 Why? An option to stop if two_level namespace can't be built, I can see
 as a good thing for people porting stuff to darwin, however some stuff
 is quite happy being flat, even if it only missing the usual environ
 symbol, and imo, libtool shouldn't die by default.
 
 The default should be to continue if possible unless told otherwise,
 the fewer people who have to add custom flags and options the better.
 
 Peter
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Help! Library reordering is killing me!

[Robert Boehne]

Norbert,

Try quoting the whole series of library flags.

Robert

Norbert Kiesel wrote:
 
 Hi,
 
 I'm a happy libtool user but currently face a problem which I just can't
 solve: I have to link a program against openldap libs (-lldap -llber)
 and oracle libs (-lclntsh), but I must make sure the openldap libs
 appear *before* the oracle lib.  Reason is that -lclntsh also contains
 LDAP functions which are not compatible with the OpenLDAP ones I need to
 use.
 
 However whatever I do, libtool always puts the -lclntsh before the
 -lldap.  Is there any way I can force it to preserve the order I gave in
 my Makefile?
 
 --nk
 
 --
 Norbert Kiesel [EMAIL PROTECTED]
 TBD Networks
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC

[Robert Boehne]

Albert,

The intent here is to satisfy those who want -DPIC but remove all
macro definition by default.  I agree with the suggestion earlier
in this thread of adding a new macro AC_LIBTOOL_PICDEF([PIC])
and we'll plan on this for the release after the next one.

Thanks,

Robert

Albert Chin wrote:
 
 On Tue, Jan 21, 2003 at 09:13:54AM +1000, Kevin Ryde wrote:
  Robert Boehne [EMAIL PROTECTED] writes:
  
   All good ideas, and I don't really have a preference for any of them.
   If you do, let me know or I'll just pick the one that looks easiest.
 
  I'd think an autoconf macro would be ok, to be used for instance
 
AC_LIBTOOL_PICDEF([-DPIC])
AC_PROG_LIBTOOL
 
  which I guess would just insert its argument into $pic_flag.
 
 Is setting a custom -DPIC really necessary? How about we just leave
 the existing -DPIC for the C and C++ tags? I don't see anything to
 gain by choosing a new default or allowing it to be set.
 
 --
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Problems with cvs-libtool and Solaris CC

[Robert Boehne]

Erik,

Could you give a bit more detail as to what the problem is?
You say it compilains about x, could you send us an
error message?

Robert

Erik Assum wrote:
 
 Hi,
 
 I'm resending this message to the libtool list as I sent it directly
 to Robert without realising that Reply-To: wasn't set.
 
 * Robert Boehne
 | If you are using CVS Libtool, then the problem is with
 | your Compiler.  If not, then CVS Libtool may fix it.
 
 Thanks alot Robert, this solved the most important part of my problem,
 since I wasn't using cvs libtool.
 
 It worked really well when running ./configure --disable-static, but
 when running ./configure  make (thus --enable-static) AR (in this
 case
 
 # The archiver.
 AR=/opt/SUNWspro/bin/CC -xar
 AR_FLAGS=-o
 
 complains on the 'x' when the line
 $run eval (cd \$xdir  $AR x \$xabs) || exit $?
 from the code below is run. Is this a but or a feature?
 
 if test -n $convenience; then
   if test -n $whole_archive_flag_spec; then
 save_libobjs=$libobjs
 eval libobjs=\\$libobjs $whole_archive_flag_spec\
   else
 gentop=$output_objdir/${outputname}x
 $show ${rm}r $gentop
 $run ${rm}r $gentop
 $show $mkdir $gentop
 $run $mkdir $gentop
 status=$?
 if test $status -ne 0  test ! -d $gentop; then
   exit $status
 fi
 generated=$generated $gentop
 
 for xlib in $convenience; do
   # Extract the objects.
   case $xlib in
   [\\/]* | [A-Za-z]:[\\/]*) xabs=$xlib ;;
   *) xabs=`pwd`/$xlib ;;
   esac
   xlib=`$echo X$xlib | $Xsed -e 's%^.*/%%'`
   xdir=$gentop/$xlib
 
   $show ${rm}r $xdir
   $run ${rm}r $xdir
   $show $mkdir $xdir
   $run $mkdir $xdir
   status=$?
   if test $status -ne 0  test ! -d $xdir; then
 exit $status
   fi
   $show (cd $xdir  $AR x $xabs)
   $run eval (cd \$xdir  $AR x \$xabs) || exit $?
 
   libobjs=$libobjs `find $xdir -name \*.$objext -print -o -name \*.lo 
-print | $NL2SP`
 done
   fi
 fi
 
 Erik.
 --
 It's a miracle that curiosity survives formal education.
 -- Albert Einstein
 * Robert Boehne
 | If you are using CVS Libtool, then the problem is with
 | your Compiler.  If not, then CVS Libtool may fix it.
 
 Thanks alot Robert, this solved the most important part of my problem,
 since I wasn't using cvs libtool.
 
 It worked really well when running ./configure --disable-static, but
 when running ./configure  make (thus --enable-static) AR (in this
 case
 
 # The archiver.
 AR=/opt/SUNWspro/bin/CC -xar
 AR_FLAGS=-o
 
 complains on the 'x' when the line
 $run eval (cd \$xdir  $AR x \$xabs) || exit $?
 from the code below is run. Is this a but or a feature?
 
 if test -n $convenience; then
   if test -n $whole_archive_flag_spec; then
 save_libobjs=$libobjs
 eval libobjs=\\$libobjs $whole_archive_flag_spec\
   else
 gentop=$output_objdir/${outputname}x
 $show ${rm}r $gentop
 $run ${rm}r $gentop
 $show $mkdir $gentop
 $run $mkdir $gentop
 status=$?
 if test $status -ne 0  test ! -d $gentop; then
   exit $status
 fi
 generated=$generated $gentop
 
 for xlib in $convenience; do
   # Extract the objects.
   case $xlib in
   [\\/]* | [A-Za-z]:[\\/]*) xabs=$xlib ;;
   *) xabs=`pwd`/$xlib ;;
   esac
   xlib=`$echo X$xlib | $Xsed -e 's%^.*/%%'`
   xdir=$gentop/$xlib
 
   $show ${rm}r $xdir
   $run ${rm}r $xdir
   $show $mkdir $xdir
   $run $mkdir $xdir
   status=$?
   if test $status -ne 0  test ! -d $xdir; then
 exit $status
   fi
   $show (cd $xdir  $AR x $xabs)
   $run eval (cd \$xdir  $AR x \$xabs) || exit $?
 
   libobjs=$libobjs `find $xdir -name \*.$objext -print -o -name \*.lo 
-print | $NL2SP`
 done
   fi
 fi
 
 Erik.
 --
 It's a miracle that curiosity survives formal education.
 -- Albert Einstein
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Unrequested F77 config

[Robert Boehne]

I think, but I'm not 100% sure, that Autoconf should be able to handle
this on it's own by only running the F77 tag configuration when the
project
is running the AC_PROG_F77 macro.  Same goes for the other tags as well.
If someone ever could figure out how to get this to actually work, they
would get a gold star.  :)

Robert

Albert Chin wrote:
 
 On Sun, Dec 22, 2002 at 10:07:32AM -0600, Bob Friesenhahn wrote:
  There are certainly a bug in that even if no fortran compiler is
  found, libtool proceeds to configure the F77 tag.  Much of this
  configuration is done with CC unset, causing various warnings.
 
  Libtool should provide a way for the user to specify which tags are to
  be configured.  This would allow a project which includes its own
  libtool, but uses a subset of the supported languages to avoid
  configuring libtool for languages which are not used.
 
 We could augment AC_PROG_LIBTOOL to take a list of tags:
   AC_PROG_LIBTOOL([tag1,tag2,...])
 
 Anyone want to submit a patch :)
 
 --
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Unrequested F77 config

[Robert Boehne]

zaufi,

The fact that Libtool currently creates a tag for F77 is known,
but it only prints out extra messages.   I've built several projects
on several systems that had no F77 compiler, and everything works fine.

Robert

zaufi wrote:
 
 Hi all!
 
 In my project I'm use libtool from CVS and _don't_ use F77, but during
 ./configure execution I'v got an error:
 
 AC_PROG_LIBTOOL messages starts here (my comments started from ):
 ...
 checking for a sed that does not truncate output... /bin/sed
 checking for egrep... grep -E
 checking for ld used by GCC... /usr/bin/ld
 checking if the linker (/usr/bin/ld) is GNU ld... yes
 checking for /usr/bin/ld option to reload object files... -r
 checking for BSD-compatible nm... /usr/bin/nm -B
 checking whether ln -s works... yes
 checking how to recognise dependent libraries... pass_all
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking dlfcn.h usability... yes
 checking dlfcn.h presence... yes
 checking for dlfcn.h... yes
 checking for g77... no
 checking for f77... no
 checking for xlf... no
 checking for frt... no
 checking for pgf77... no
 checking for fl32... no
 checking for af77... no
 checking for fort77... no
 checking for f90... no
 checking for xlf90... no
 checking for pgf90... no
 checking for epcf90... no
 checking for f95... no
 checking for fort... no
 checking for xlf95... no
 checking for lf95... no
 checking for g95... no
 checking whether we are using the GNU Fortran 77 compiler... no
  note what F77 not found in my system
  continue configure messages...
 
 checking whether  accepts -g... no
  I suppose smth missed here between words 'whether' and 'accepts'... --
  maybe substitution of undefined shell variable??
  continue configure messages...
 
 checking the maximum length of command line arguments... 32768
 checking command to parse /usr/bin/nm -B output from gcc object... ok
 checking for objdir... .libs
 checking for ranlib... ranlib
 checking for strip... strip
 checking if gcc static flag  works... yes
 checking if gcc supports -fno-rtti -fno-exceptions... yes
 checking for gcc option to produce PIC... -fPIC
 checking if gcc PIC flag -fPIC works... yes
 checking if gcc supports -c -o file.o... yes
 checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... no
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking for shl_load... no
 checking for shl_load in -ldld... no
 checking for dlopen... no
 checking for dlopen in -ldl... yes
 checking whether a program can dlopen itself... yes
 checking whether a statically linked program can dlopen itself... yes
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 configure: creating libtool
 appending configuration tag CXX to libtool
 checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
 checking for g++ option to produce PIC... -fPIC
 checking if g++ PIC flag -fPIC works... yes
 checking if g++ supports -c -o file.o... yes
 checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... yes
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking for shl_load... (cached) no
 checking for shl_load in -ldld... (cached) no
 checking for dlopen... (cached) no
 checking for dlopen in -ldl... (cached) yes
 checking whether a program can dlopen itself... (cached) yes
 checking whether a statically linked program can dlopen itself... (cached) yes
 appending configuration tag F77 to libtool
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking for  option to produce PIC... -fPIC
 checking if  PIC flag -fPIC works... no
 checking if  supports -c -o file.o... no
 checking whether the  linker (/usr/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... yes
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking dynamic linker characteristics... ./configure: line 1:
 -print-search-dirs: command not found
 GNU/Linux ld.so
  OOPS!!!
 
 Why it is needed to configure F77 when I even have no it installed???
 Currently I comment the following lines in libtool.m4
 
 dnl And a 

Re: Building shared C++ libraries

[Robert Boehne]

Dalibor,

The key is to use the latest CVS version of Libtool
which includes full multi-language support.
ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
Until 1.5 is released, you'll have to use CVS Libtool.

Robert


Dalibor Topic wrote:
 
 Hi,
 
 I'd like to know if it is possible to build shared C++
 libraries with libtool, and if so, how? The libtool
 documentation is very vague on that issue, but I've
 seen some comments on the mailing lists indicating
 that it could be possible.
 
 the background to my query is that libtool 1.4.3 on
 i386-linux when trying to link c++ code to shared
 libraries uses gcc instead of g++. So it forgets to
 link in -lstdc++ and -lg++ .
 
 best regards,
 
 dalibor topic
 
 __
 Do you Yahoo!?
 Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
 http://mailplus.yahoo.com
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [shell functions, was RE: solving of name conflicts inincluded.a]

[Robert Boehne]

Tom,

Are you volunteering to convert the shell functions in CVS Libtool
into non-shell-function code?  I would like to see this discussion
go in a different direction.  I would like to see a list of the
platforms known to NOT have shell functions in their Bourne shells.
My point is that there are systems out there that Libtool does
not support currently, even before it had a shell function in it.
So we're not trying to write code that runs on every computer
that ever existed, so there is a trade off between portability
and maintainability, and a line to draw.  I don't think it is
reasonable for any of us to decide where that line is if we
don't know who it might effect.
Digital Eq.'s Ultrix is the only one I'm aware of, are there any more?

Robert


Tom Lord wrote:
 
 I don't see the urgency to move to shell functions, but I do
 see how they can simplify our lives.
 
 
 Uh... if not now, when?
 
 Seriously, there's _always_ commercial incentive to do a half assed
 job and the _real_ ego competition is to reject that incentive and do
 a good job anyway.
 
 Ties are nooses, in a pinch.
 
 -t
 
 ___
 Libtool-patches mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool-patches


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: no AIX 5 support? I've got some idea what's needed.

[Robert Boehne]

Gary:

Have you tried CVS?  Libtool has support for IA64 AIX which
only comes in version 5 of AIX.

Robert

Gary Kumfert wrote:
 
 Hi,
 
 I've found no support for AIX 5 in automake, autoconf,
 or libtool (not even config.guess!).
 
 Any libtool developer interested in teaming up to add
 AIX 5.x support to libtool?  I have a handful
 of settings that I tweeked by hand to get things working
 right.  I can just describe what settings are ultimately needed,
 or try to hack the changes into scripts and send the diffs.
 
 I'd be willing to work with someone to refine the code
 if I'm the only one with access to an AIX 5.x box.
 
 Regards,
 
 Gary
 
 
   Gary Kumfert, Ph.D.   [EMAIL PROTECTED]
   Center for Applied Scientific Computing  phone: 925-424-2580
   Lawrence Livermore National Laboratory   fax:   925-423-9338
   P.O. Box 808,L-551
   Livermore, CA 94551-0808
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [shell functions, was RE: solving of name conflicts in included.a]

[Robert Boehne]

All,

Hey, that's a relief, now we don't have to deal with this
issue anymore.  I would be in favor of a) leaving the
shell functions in place, and b) making use of them more.
 
Thanks,

Robert

Bruce Korb wrote:
 
 Alexandre Duret-Lutz wrote:
 
   Bruce ... 20 year old shells are [not] too old for continued
   Bruce support.  Ick.  How completely disgusting.
 
  Cheer up and read the Autoconf 2.54c announcement entirely :)
 
 You're right.  I only read the first 100 lines or so.  :-)
 This is a decade overdue.  ;-)  But still, at the usual
 release rate, libtool's use is still over the horizon.  :-(
 
 ___
 Libtool-patches mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool-patches


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool

[Robert Boehne]

Halberstadt,

It looks to me like your gcc or libc is broken, the symbol
it can't seem to find is internal, prefixed with __.
If I had to guess, it's probably your gcc installation.

Robert

Halberstadt wrote:
 
 Hello,
 
 i want to compile libtool. But i received by exwecuting the 'make'
 command the following message:
 
 cd libtool-1.4.3
 bash-2.03# ./configure
 creating cache ./config.cache
 checking for a BSD compatible install... ./install-sh -c
 checking whether build environment is sane... yes
 checking whether make sets ${MAKE}... yes
 checking for working aclocal... missing
 checking for working autoconf... found
 checking for working automake... missing
 checking for working autoheader... found
 checking for working makeinfo... missing
 checking for gcc... gcc
 checking whether the C compiler (gcc  ) works... yes
 checking whether the C compiler (gcc  ) is a cross-compiler... no
 checking whether we are using GNU C... yes
 checking whether gcc accepts -g... yes
 checking host system type... sparc-sun-solaris2.8
 checking build system type... sparc-sun-solaris2.8
 checking for ld used by GCC... /usr/ccs/bin/ld
 checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
 checking for BSD-compatible nm... /usr/ccs/bin/nm -p
 checking whether ln -s works... yes
 checking for Cygwin environment... no
 checking for mingw32 environment... no
 checking how to run the C preprocessor... gcc -E
 checking for /usr/ccs/bin/ld option to reload object files... -r
 checking for a sed that does not truncate output... /usr/xpg4/bin/sed
 checking how to recognise dependent libraries... pass_all
 checking for object suffix... o
 checking for executable suffix... no
 checking command to parse /usr/ccs/bin/nm -p output... ok
 checking for dlfcn.h... yes
 checking for ranlib... ranlib
 checking for strip... strip
 checking for objdir... .libs
 checking for gcc option to produce PIC... -fPIC
 checking if gcc PIC flag -fPIC works... yes
 checking if gcc static flag -static works... yes
 checking if gcc supports -c -o file.o... yes
 checking if gcc supports -c -o file.lo... yes
 checking if gcc supports -fno-rtti -fno-exceptions... yes
 checking whether the linker (/usr/ccs/bin/ld) supports shared
 libraries... yes
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... no
 checking dynamic linker characteristics... solaris2.8 ld.so
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking for shl_load... no
 checking for shl_load in -ldld... no
 checking for dlopen... no
 checking for dlopen in -ldl... yes
 checking whether a program can dlopen itself... yes
 checking whether a statically linked program can dlopen itself... no
 creating libtool
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 creating doc/Makefile
 creating tests/Makefile
 configuring in libltdl
 running /bin/sh ./configure  --enable-ltdl-install
 --cache-file=.././config.cache --srcdir=.
 loading cache .././config.cache
 checking for a BSD compatible install... ./../install-sh -c
 checking whether build environment is sane... yes
 checking whether make sets ${MAKE}... (cached) yes
 checking for working aclocal... missing
 checking for working autoconf... found
 checking for working automake... missing
 checking for working autoheader... found
 checking for working makeinfo... missing
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for gcc... (cached) gcc
 checking whether the C compiler (gcc  ) works... yes
 checking whether the C compiler (gcc  ) is a cross-compiler... no
 checking whether we are using GNU C... (cached) yes
 checking whether gcc accepts -g... (cached) yes
 checking for working const... yes
 checking for inline... inline
 checking for Cygwin environment... (cached) no
 checking for mingw32 environment... (cached) no
 checking how to run the C preprocessor... (cached) gcc -E
 checking host system type... sparc-sun-solaris2.8
 checking build system type... sparc-sun-solaris2.8
 checking for ld used by GCC... (cached) /usr/ccs/bin/ld
 checking if the linker (/usr/ccs/bin/ld) is GNU ld... (cached) no
 checking for /usr/ccs/bin/ld option to reload object files... (cached) -r
 checking for BSD-compatible nm... (cached) /usr/ccs/bin/nm -p
 checking for a sed that does not truncate output... (cached)
 /usr/xpg4/bin/sed
 checking whether ln -s works... (cached) yes
 checking how to recognise dependent libraries... (cached) pass_all
 checking for object suffix... (cached) o
 checking for executable suffix... (cached) no
 checking command to parse /usr/ccs/bin/nm -p output... (cached) ok
 checking for dlfcn.h... (cached) yes
 checking for ranlib... (cached) ranlib
 checking for strip... (cached) strip
 checking for objdir... .libs
 checking for gcc option to produce PIC... (cached)  -fPIC
 checking if gcc PIC flag  

Re: ./configure: -print-search-dirs: command not found

[Robert Boehne]

Bob,

There used to be a similar-looking problem with the GCJ tag,
but since that was fixed, this is likely different.
I suspect that this is an Autoconf/Automake usage problem,
or perhaps a bug in one of these.  I get warning message
about F77 Autoconf/Automake macros when bootstrapping,
so the problem, I suspect, lies therin.  I'm posting this
because it isn't likely I'll get to it very soon, so at
least someone else would have the minimal background I gave here.

Thanks,

Robert

Bob Friesenhahn wrote:
 
 CVS libtool prints an error message which implies that CC is not set
 when configuring for Fortran if no Fortran compiler is found.
 Libtool's Fortran support should be more graceful than this.  Ideally
 it would short-circuit the Fortran configuration if no Fortran
 compiler is found.  At a minimum, it shouldn't cause error messages to
 be printed.
 
 checking for g77... no
 checking for f77... no
 checking for xlf... no
 checking for frt... no
 checking for pgf77... no
 checking for fl32... no
 checking for af77... no
 checking for fort77... no
 checking for f90... no
 checking for xlf90... no
 checking for pgf90... no
 checking for epcf90... no
 checking for f95... no
 checking for fort... no
 checking for xlf95... no
 checking for lf95... no
 checking for g95... no
 checking whether we are using the GNU Fortran 77 compiler... no
 .
 .
 .
 appending configuration tag F77 to libtool
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking for  option to produce PIC... -fPIC
 checking if  PIC flag -fPIC works... no
 checking if  supports -c -o file.o... no
 checking whether the  linker (/usr/ccs/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... yes
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... no
 checking dynamic linker characteristics... ./configure: -print-search-dirs: command 
not found
 solaris2.9 ld.so
 
 Can a maintainer of libtool's Fortran support attend to this or
 submit a patch?
 
 Bob
 ==
 Bob Friesenhahn
 [EMAIL PROTECTED]
 http://www.simplesystems.org/users/bfriesen
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Robert Boehne]

All,

The max_cmd_len variable is used to determine how long a command
can be executed.  When Libtool generates a link command that is
longer than this, it breaks the command into successive ld -r
invocations that are just short enough to be executed.  There are
other parts of the commands that aren't included when testing, so
the max_cmd_len variable can't be set to the actual limit, but
must be smaller.  Also, finding the actual limit would take much
longer so we set max_cmd_len to something safe.
  It is true that the checking takes some time, ~three seconds on
a newer Sun workstation (with large limit), but it isn't clear
to me why it would take even longer under MinGW.
  It is reasonable to set this to a hard limit if the test takes
a very long time, but the value to use is the same one that
Libtool's configury will calculate.  The problem with GTK+ is
that they archive two (or more) object files with the same name,
so successive ar commands replace the previous one with the
new one.  If a package needs the command line broken up, setting
this value to the maximum possible will speed up compilation
drastically, IMHO an important issue.

my $0.02

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 1.4.3

[Robert Boehne]

All,

I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources.  Any properly formatted patches will
be considered for inclusion before the release.  I have
seen a tendency to post patches on any list in any
format, which makes it more work to get that particular
patch installed in CVS.  As of late, Gary and I have
precious little of that!

I may get a chance to review some patches before the
weekend (with a little luck) but likely I'll have
to go it alone on Saturday.

After 1.4.3 is released, branch-1-4 will no longer
be maintained.  A release of 1.5 should follow shortly.

Ok?

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Robert Boehne]

Benjamin,

If we added support for library namespace, all of the
Darwin developers would start developing software with
Libtool that used it, and therefore wouldn't link on
other systems, correct?  I'm not claiming I have ever
seen a Mac running X+ so you'll have to correct me if I'm wrong.
  Libtool's philosophy is mostly to provide the common
subset of linker/loader/compiler features, and to specifically
NOT support features that aren't available elsewhere.  Now,
this isn't always the case, but if you wanted to add support
for library namespaces for other platforms *IN_Libtool*
then it would be reasonable, but more work.  I doubt that
is possible anyway.

HTH,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 1.4.3

[Robert Boehne]

Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??

What platforms (aside from Alpha  RS/6000) does this work on?

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Robert Boehne]

Ok,

So a 1.4.3 version is desired, that's established.
The million-dollar question is:
   Does current branch-1-4 Libtool do the trick?

If so, then a roll out could be done within the week.

Robert


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT gnu DOT org


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.2 and EBCDIC

[Robert Boehne]

Howard,

This was installed already.

Thanks,
 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT gnu DOT org


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Porting libtool to linux-icc (mark II) [PATCH]

[Robert Boehne]

Hello,

I've approved this patch pending copyright assignment.

ChangeLog entry:
2002-09-24  Allan Sandfeld Jensen  [EMAIL PROTECTED]

* libtool.m4: Add support for Intel icc compiler for Linux.

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com




Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.264
diff -u -r1.264 libtool.m4
--- libtool.m4  10 Sep 2002 13:50:06 -  1.264
+++ libtool.m4  24 Sep 2002 23:06:32 -
@@ -2425,7 +2425,7 @@
 _LT_AC_TAGVAR(compiler, $1)=$CC
 cc_basename=`$echo X$compiler | $Xsed -e 's%^.*/%%'`
 
-# We don't want -fno-exception wen compiling C++ code, so set the
+# We don't want -fno-exception when compiling C++ code, so set the
 # no_builtin_flag separately
 if test $GXX = yes; then
   _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'
@@ -2803,6 +2803,19 @@
# dependencies.
output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 
21 | grep ld`; templist=`echo $templist | sed s/\(^.*ld.*\)\( .*ld .*$\)/\1/`; 
list=; for z in $templist; do case $z in conftest.$objext) list=$list $z;; 
*.$objext);; *) list=$list $z;;esac; done; echo $list'
;;
+  icpc)
+   # Intel C++
+   with_gnu_ld=yes
+   
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+   _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects 
+$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
+   _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects 
+$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname 
+${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+
+   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+   _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+   
+   _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive$convenience 
+${wl}--no-whole-archive'
+   ;;
 esac
 ;;
   lynxos*)
@@ -4220,6 +4233,12 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
+ icpc)
+   # Intel C++
+   _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption,ld,'
+   _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+   ;; 
  *)
;;
esac
@@ -4416,7 +4435,13 @@
   # PIC (with -KPIC) is the default.
   _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
   ;;
-
+linux*)
+  if test $CC = icc; then
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption,ld,'
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+  fi
+  ;;
 newsos6)
   _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
   _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5260,6 +5285,9 @@
 # Do we need to explicitly link libc?
 #
 _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
+if test $enable_shared = yes  test $CC = icc; then
+  _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+fi
 if test $enable_shared = yes  test $GCC = yes; then
   case $_LT_AC_TAGVAR(archive_cmds, $1) in
   *'~'*)

Re: PATCH: pointless code removal

[Robert Boehne]

Bruce:

Now that I look at it, it may be better to remove
that initial space from $base_compile.

Any thoughts on that?

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: pointless code removal

[Robert Boehne]

Bruce,

Ok, I found a big problem here, it seems that
currently Libtool will ignore all tags, and use
CC in every case.  That's bad.  But along the
reasoning that spurned your original patch, I don't
want to un-do it.  I will work on a proper fix
if I can figure out how Libtool ever managed to process
it's arguments.  ;)

Rob

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: pointless code removal

[Robert Boehne]

Bruce,

Ok, I found the problem.  Before your recent patch, either
$base_compile never had a space as it's first character, or
it was stripped out somewhere (maybe by accident?).
Regardless, the problem was that in the check for a valid
tag, $base_compile= $CC ... was not checked for, and THAT
was what caused it to fail.
This patch removes the default (which actually overrides
all tags!) setting of tagname, and adds cases to check for
base_compile with a space prepended.

This is an obvious bug fix, so I'm checking it in now.

ChangeLog entry:
2002-04-01  Robert Boehne  [EMAIL PROTECTED]

* ltmain.in : Handle the case when no tag is explicitly set, and
$base_compile has a space in front of $CC, and revert the setting
of tagname checked in on 2002-3-14.

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]


Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.290
diff -u -r1.290 ltmain.in
--- ltmain.in   14 Mar 2002 21:43:50 -  1.290
+++ ltmain.in   1 Apr 2002 22:27:49 -
@@ -105,9 +105,6 @@
 lo2o=s/\\.lo\$/.${objext}/
 o2lo=s/\\.${objext}\$/.lo/
 
-# set the tag name so that it defaults to CC
-tagname=CC
-
 # Parse our command line options once, thoroughly.
 while test $# -gt 0
 do
@@ -470,11 +467,15 @@
 # Only attempt this if the compiler in the base compile
 # command doesn't match the default compiler.
 if test -n $available_tags  test -z $tagname; then
-  case $base_compile  in
-  $CC *) ;;
+  case $base_compile in
   # Blanks in the command may have been stripped by the calling shell,
   # but not from the CC environment variable when ltconfig was run.
+  $CC *) ;;
+  # Blanks at the start of $base_compile will cause this to fail
+  # if we don't check for them as well.
+   $CC *) ;;
   `$echo $CC` *) ;;
+   `$echo $CC` *) ;;
   *)
for z in $available_tags; do
  if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $z$  $0  /dev/null; then
@@ -1520,10 +1521,14 @@
 # command doesn't match the default compiler.
 if test -n $available_tags  test -z $tagname; then
   case $base_compile in
-  $CC *) ;;
   # Blanks in the command may have been stripped by the calling shell,
   # but not from the CC environment variable when ltconfig was run.
+  $CC *) ;;
+  # Blanks at the start of $base_compile will cause this to fail
+  # if we don't check for them as well.
+   $CC *) ;;
   `$echo $CC` *) ;;
+   `$echo $CC` *) ;;
   *)
for z in $available_tags; do
  if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $z$  $0  /dev/null; then

Re: building static on AIX

[Robert Boehne]

Under AIX, both shared and static libraries are
named lib*.a, so by default we don't build static
libraries, i.e. you get one or the other.  When the
library is shared, the archvie file contains one
member, the shared library.  This is how shared
libraries are typically done under AIX, if you're having
some problem with it, it isn't becuase it just doesn't work.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: building static on AIX

[Robert Boehne]

Samuel:

Yes, that clears it up.  I agree with you, and
I was not aware of this behavior.

Robert

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: pointless code removal

[Robert Boehne]

Bruce:

I found a few things to improve on.  These are pretty
minor changes that fix an obvious problem, so I'm
going to take the liberty of checking them in asap.

Thanks!

2002-03-14  Robert Boehne  [EMAIL PROTECTED]

ltmain.in: Touch-up to make testsuite pass, and default tagname
to CC when it isn't explicitly set.


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

? install-sh
? mkinstalldirs
? missing
? INSTALL
? COPYING
? gcj.patch
? fixups.patch
? demo/hell_static
? depdemo/depdemo_static
? libltdl/config-h.in
? mdemo/mdemo_static
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.289
diff -u -r1.289 ltmain.in
--- ltmain.in   12 Mar 2002 02:30:33 -  1.289
+++ ltmain.in   14 Mar 2002 21:35:01 -
@@ -105,6 +105,9 @@
 lo2o=s/\\.lo\$/.${objext}/
 o2lo=s/\\.${objext}\$/.lo/
 
+# set the tag name so that it defaults to CC
+tagname=CC
+
 # Parse our command line options once, thoroughly.
 while test $# -gt 0
 do
@@ -324,7 +327,8 @@
 do
   case $arg_mode in
   arg  )
-   lastarg=$arg  # do not continue.  Instead, add this to base_compile
+   # do not continue.  Instead, add this to base_compile
+   lastarg=$arg
arg_mode=normal
;;
 

Re: ltconfig problem

[Robert Boehne]

Alex:

If your version is new enough, there isn't an ltconfig anymore.
Hard to say without telling us what version you have though...

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: /usr/bin/ar: arg list too long

[Robert Boehne]

Samuel:

CVS head and the latest alpha libtool have this fixed.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: Fix mips*-*-linux*

[Robert Boehne]

Alexandre:

You have my approval to un-do my mistsake.  If I had understood
exactly what this patch was doing then I would have rejected it myself.
H.J. As I now understand it, your patch doesn't improve anything,
it just breaks static linking (where you'd actually need the dependent
archive).  When linking shared the archive is already pulled into the
*.so, so it isn't actually dependent on the archive.

- Robert

Alexandre Oliva wrote:

 On Oct 23, 2001, Robert Boehne [EMAIL PROTECTED] wrote:

  Here is the patch reworked for HEAD.  If noone objects
  I'll commit it.

 *wakes up*
 *stretches*
 *yawns*
 *looks around*

 *thinks*

 -- Hmm...  It's been a long time since I last posted in
libtool-patches.  In fact, it's been a while since I last opened
its mail folder, so I had completely missed this one.  I wonder if
it's too late...

 *shouts*

 -- OBJECTION!

 *looks at the CVS repo*
 *thinks*

 -- Hmm...  No, it *was* too late :-(

 Oh, well.  I really think this shouldn't have gone in, for the reasons
 brought up in gcc-patches and libtool mailing lists.  But, after such
 a long silence, I don't feel I'm entitled to just come back and start
 checking in or reverting patches, so...  Ok to revert that patch, by
 checking this one in?  Tested on athlon-pc-linux-gnu, no regressions,
 so this must be right for at least GNU/Linux/x86, right? ;-)

 For the record, the reason is that, contrary to the claim in the
 patch, on a number of OSs it's not safe to link a static library into
 a shared library and, on those in which it is safe, using file_magic
 is pointless: pass_all is supposed to behave exactly the way
 H.J. intended.

 Sorry for having dropped the ball for so long.  It's too bad I don't
 foresee this changing in the near future :-(

   
 Index: ChangeLog
 from  Alexandre Oliva  [EMAIL PROTECTED]

 Reverted incorrect patch:
 2001-10-24  H.J. Lu  [EMAIL PROTECTED]
 * ltmain.sh: Allow link against an archive when building a
 shared library.
 * libtool.m4 (lt_cv_deplibs_check_method): Always use
 file_magic for Linux ELF.

 Index: ltmain.in
 ===
 RCS file: /cvsroot/libtool/libtool/ltmain.in,v
 retrieving revision 1.286
 diff -u -p -r1.286 ltmain.in
 --- ltmain.in 29 Jan 2002 22:58:35 - 1.286
 +++ ltmain.in 7 Feb 2002 06:58:05 -
 @@ -2990,13 +2990,6 @@ EOF
 *) potlib=`$echo X$potlib | $Xsed -e 
's,[^/]*$,,'`$potliblink;;
 esac
   done
 - # It is ok to link against an archive when
 - # building a shared library.
 - if $AR -t $potlib  /dev/null 21; then
 -   newdeplibs=$newdeplibs $a_deplib
 -   a_deplib=
 -   break 2
 - fi
   if eval $file_magic_cmd \\$potlib\ 2/dev/null \
  | ${SED} 10q \
  | egrep $file_magic_regex  /dev/null; then
 Index: libtool.m4
 ===
 RCS file: /cvsroot/libtool/libtool/libtool.m4,v
 retrieving revision 1.247
 diff -u -p -r1.247 libtool.m4
 --- libtool.m4 30 Jan 2002 16:39:24 - 1.247
 +++ libtool.m4 7 Feb 2002 06:58:08 -
 @@ -1949,7 +1949,6 @@ linux*)
  # glibc up to 2.1.1 does not perform some relocations on ARM
  lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared 
object|dynamic lib )' ;;
esac
 -  lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared 
object|dynamic lib )'
lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
;;


   

 --
 Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
 Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
 CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
 Free Software EvangelistProfessional serial bug killer

--
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: different library versions

[Robert Boehne]

You can't mix C++ from GCC 2.x with C++ from GCC 3.x.
The name mangling is different, and there isn't anything
libtool can do about it.  You need to always use GCC 3
or always use gcc 2.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Building projects on i386-pc-solaris2.8

[Robert Boehne]

Allan:

It helps to specify the verson of Libtool you're using as well
as the actual link line that Libtool creates.  For my money
I can't think of any reason why the link line you have here
should work.  It doesn't specify that you want to create
a shared library.

Rob


Allan McIntosh wrote:
 
 On the solaris machine there are 3 linkers:
 
 /opt/sfw/bin/ld
 /usr/ucb/ld
 /usr/ccs/bin/ld
 
 If I do a `which ld` it returns /opt/sfw/bin/ld
 /opt/sfw/bin/c++
 
 [amcintosh@amcintosh 11:57:49 src]# ls -la /opt/sfw/bin/c++
 -r-xr-xr-x   2 root bin74868 May 21  2001 /opt/sfw/bin/c++
 [amcintosh@amcintosh 11:58:06 src]# /opt/sfw/bin/c++ -v
 Reading specs from /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/specs
 gcc version 2.95.3 20010315 (release)
 
 Then if I simply compile from the command line:
 
 c++  -o libagent.so -fPIC -L/usr/local/lib -G Agent.o AgentObject.o
 AgentObjectLinux.o AgentObjectFactory.o Vector.o  Attribute.o
 SharedLibrary.o SharedLibraryMgr.o Storage.o StorageFile.o
 AttributeContainer.o ObjectContainer.o AgentObjectVersion.o ODParser.o
 XMLParser.o XMLItem.o md5.o -lcrypt -ldl -lltapi12 -lltstd12 -lz
 
 The library builds fine.  But if I  use libtool to build it. I get
 many undefined symbols.
 
 The libtool script has:
 
 LD=/usr/ccs/bin/ld
 
 If i change LD=/opt/sfw/bin/ld is that enough? Or must I define
 LD_RUN_PATH and recompile libtool?
 
 any suggestions?
 
 Thanks in advance.
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: How about this?

[Robert Boehne]

Allan:

ld doesn't work for linking c++, so you need to have an
alpha version (or CVS HEAD) of Libtool to do this.

Robert

Allan McIntosh wrote:
 
 I don't believe my question is bug related. I am just seeking advice,
 having struggled way to long with this.
 
 In my hand written  Makefile I have the following:
 
 g++ -MD -fPIC -c source1.c
 g++ -MD -fPIC -c source2.c
 g++ -MD -fPIC -c source3.c
 
 and so on up untill:
 
 g++ -o libagent.so -fPIC -L/usr/local/lib -G Agent.o AgentObject.o
 AgentObjectLinux.o AgentObjectFactory.o Vector.o Attribute.o
 SharedLibrary.o SharedLibraryMgr.o Storage.o StorageFile.o
 AttributeContainer.o ObjectContainer.o AgentObjectVersion.o ODParser.o
 XMLParser.o XMLItem.o md5.o -lcrypt -ldl -lltapi12 -lltstd12 -lz g++ -o
 
 g++ -o agent -fPIC AGENT_grammar.o AGENT_tokens.o main.o -lfl -lsocket -lnsl -lagent
 
 Providing me with libagent.so and agent.
 
 ---
 
 Using Autotools and libtool do the following:
 
 Makefile.am:
 
 lib_LTLIBRARIES = libagent.la
 libagent_la_SOURCES = Agent.cc AgentObject.cc AgentObjectLinux.cc 
AgentObjectFactory.cc\
  Vector.cc  Attribute.cc SharedLibrary.cc SharedLibraryMgr.cc\
  Storage.cc StorageFile.cc AttributeContainer.cc ObjectContainer.cc 
AgentObjectVersion.cc\
  ODParser.cc XMLParser.cc XMLItem.cc md5.cc
 
 libagent_la_LDFLAGS = -L/usr/local/lib
 libagent_la_DEPENDENCIES =
 libagent_la_LIBADD =
 
 compile output:
 
 source='AgentObject.cc' object='AgentObject.lo' libtool=yes \
 depfile='.deps/AgentObject.Plo' tmpdepfile='.deps/AgentObject.TPlo' \
 depmode=gcc /bin/sh ../depcomp \
 /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I..  -I../src 
-I/usr/local/include  -g -O2 -c -o AgentObject.lo `test -f
 AgentObject.cc || echo './'`AgentObject.cc
 rm -f .libs/AgentObject.lo
 g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/include -g -O2 -c 
AgentObject.cc -Wp,-MD,.deps/AgentObject.TPlo  -fPIC -DPIC -o
 .libs/AgentObject.lo
 g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/include -g -O2 -c 
AgentObject.cc -Wp,-MD,.deps/AgentObject.TPlo -o AgentObject.o /dev/null
 21
 mv -f .libs/AgentObject.lo AgentObject.lo
 
 All the way down to:
 
 /bin/sh ../libtool --mode=link g++ -g -O2 -o libagent.la -rpath
 /home/agent/lib -L/usr/local/lib Agent.lo AgentObject.lo
 AgentObjectLinux.lo AgentObjectFactory.lo Vector.lo Attribute.lo
 SharedLibrary.lo SharedLibraryMgr.lo Storage.lo StorageFile.lo
 AttributeContainer.lo ObjectContainer.lo AgentObjectVersion.lo ODParser.lo
 XMLParser.lo XMLItem.lo md5.lo -lnsl -lz -lltstd12 -lltapi12 -lfl -ldl
 -lcrypt -lsocket
 rm -fr .libs/libagent.la .libs/libagent.* .libs/libagent.*
 /usr/ccs/bin/ld -G -h libagent.so.0 -o .libs/libagent.so.0.0.0 Agent.lo
 AgentObject.lo AgentObjectLinux.lo AgentObjectFactory.lo Vector.lo
 Attribute.lo SharedLibrary.lo SharedLibraryMgr.lo Storage.lo
 StorageFile.lo AttributeContainer.lo ObjectContainer.lo
 AgentObjectVersion.lo ODParser.lo XMLParser.lo XMLItem.lo md5.lo
 -L/usr/local/lib -lnsl -lz -lltstd12 -lltapi12 -lfl -ldl
 -lcrypt -lsocket -lc
 
 (cd .libs  rm -f libagent.so.0  ln -s libagent.so.0.0.0 libagent.so.0)
 (cd .libs  rm -f libagent.so  ln -s libagent.so.0.0.0 libagent.so)
 ar cru .libs/libagent.a Agent.o AgentObject.o AgentObjectLinux.o
 AgentObjectFactory.o Vector.o Attribute.o SharedLibrary.o
 SharedLibraryMgr.o Storage.o StorageFile.o AttributeContainer.o
 ObjectContainer.o AgentObjectVersion.o ODParser.o XMLParser.o XMLItem.o
 md5.o
 ranlib .libs/libagent.a
 creating libagent.la
 (cd .libs  rm -f libagent.la  ln -s ../libagent.la libagent.la)
 
 The lib tool version segfaults on start up. Therefore I can not debug it.
 What exactly is the difference? I am on the verge of removing the libtool
 portion of the build process on i386-pc-solaris2.8.
 
 Thanks again in advance.
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Shared libraries management in Linux

[Robert Boehne]

Denis:

I don't think your question is relevant to the Libtool
mailing list.  What you are asking for is a configure
script that will create Makefiles and (config) headers
that are independent of compiler, which is not what
Autoconf is designed to do.

Robert

Denis Vlasenko wrote:
 
 Hi,
 
 I wanted to play a little with KDE 2.2.2 source and had problems with shared
 libraries. I had similar problems before and worked around them.
 
 Now I decided to sort it out once and for all.
 
 Problem description:
 
 Long ago I compiled GCC 3.0.1 from sources and put it all in /usr/lib/gcc301.
 
 After some time I decided that using /usr/lib for installed packages is not
 ok: it is for libraries only. I want to get rid of dual-purpose dirs.
 So I started to put newly compiled packages under /usr/app. I specify all
 target directories during configure to point to /usr/app/coolpackage-1.2.3
 
 In order to make binaries, man pages etc easily accessible I decided to
 symlink all relevant files (via shell script):
 /usr/bin/xyzzy -/usr/app/coolpackage-1.2.3/bin/xyzzy
 /usr/man/man8/xyzzy.8.man - /usr/app/coolpackage-1.2.3/man/man8/xyzzy8.man
 /usr/lib/xyzzy.so - /usr/app/coolpackage-1.2.3/lib/xyzzy.so
 
 However, authors of those packages don't know of my cool scheme and devise
 their own means to preserve knowledge of where package was installed.
 I thought it won't mess up but it did. Please read on.
 
 I compiled KDE 2.2.2 from sources, targeting it to /usr/app/kde-2.2.2
 It went mostly fine (minor compilations problems).
 
 Then I compiled new GCC 3.0.3 to get rid of kernel miscompilation problem
 (GCC bug). Targeted to /usr/app/gcc-3.0.3. This went fine too.
 
 Now I modified some KDE sources and typed 'make'. *Gotcha*! KDE remembers
 that it was compiled with GCC 3.0.1 and wants some libraries from
 /usr/lib/gcc301/lib/*. These libraries *is* available from newer GCC 3.0.3
 and even present in /usr/lib (in the form of symlinks to
 /usr/app/gcc-3.0.3/lib/*) but this is not enough.
 
 I can work around this. But I _don't want_ to. I want to do it _right_.
 I don't want to needlessly recompile packages like KDE when I upgrade
 compiler to next minor release. Or when I upgrade audiofile.
 'Faking' /usr/lib/gcc301/lib/xxx/yyy/zzz is out of the question too.
 
 It seems to be that library management in Linux either isn't standardized of
 too weird for me to understand it. I am very willing to RTFM if it exist.
 
 I'd be immensely grateful if someone would tell me how to manage libraries
 right. For example, tell me how you do it if your method does not involve
 ugly workarounds.
 
 PS. What's in those .la files in kde/lib/* dir? Why does kde insist on
 remembering where dependent libraries are? Is that a part of a problem?
 --
 vda
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool for C++

[Robert Boehne]

Steve:

It is NOT up-to-date for CVS HEAD and alpha versions of Libtool.

Robert

Steve M. Robbins wrote:
 
 Hello,
 
 The libtool manual suggests strongly that one not use it
 for C++ libraries.
 
 Is this section of the document up-to-date with the stable
 release of libtool?  CVS libtool?
 
  from libtool manual -
 
 11.1 Writing libraries for C++
 
 Creating libraries of C++ code should be a fairly straightforward
 process, because its object files differ from C ones in only three
 ways:
 
   1.Because of name mangling, C++ libraries are only usable by
 the C++ compiler that created them. This decision was made
 by the designers of C++ in order to protect users from
 conflicting implementations of features such as constructors,
 exception handling, and RTTI.
 
   2.On some systems, the C++ compiler must take special actions
 for the dynamic linker to run dynamic (i.e., run-time)
 initializers. This means that we should not call `ld' directly to
 link such libraries, and we should use the C++ compiler
 instead.
 
   3.C++ compilers will link some Standard C++ library in by
 default, but libtool does not know which are these libraries, so
 it cannot even run the inter-library dependence analyzer to
 check how to link it in. Therefore, running `ld' to link a C++
 program or library is deemed to fail. However, running the
 C++ compiler directly may lead to problems related with
 inter-library dependencies.
 
 The conclusion is that libtool is not ready for general use for C++
 libraries. You should avoid any global or static variable
 initializations that would cause an initializer element is not
 constant error if you compiled them with a standard C compiler.
 
 There are other ways of working around this problem, but they are
 beyond the scope of this manual.
 
 Furthermore, you'd better find out, at configure time, what are the
 C++ Standard libraries that the C++ compiler will link in by
 default, and explicitly list them in the link command line.
 Hopefully, in the future, libtool will be able to do this job by itself.
 
 -
 
 From this section, it is unclear whether libtool uses the C++
 compiler or ld to do the linking.  If the former, then it sounds
 like the remaining hurdle (from #3) is to discover with which
 standard libraries the compiler is linking.  Is this accurate?
 
 -Steve
 
 --
 by Rocket to the Moon,
 by Airplane to the Rocket,
 by Taxi to the Airport,
 by Frontdoor to the Taxi,
 by throwing back the blanket and laying down the legs ...
 - They Might Be Giants
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Libtool alpha release 1.4d now available

[Robert Boehne]

The Libtool team is happy to announce the alpha release
of Libtool 1.4d.  Tarballs and diffs against the previous
development release are available at

ftp://alpha.gnu.org/gnu/libtool/

from NEWS:

New in 1.4d: 2002-01-07; CVS version 1.4c, Libtool team:
* Help strings display correctly again.
* Better error messages when library linking fails.
* Better error messages from libltdl when loading fails.
* Better search path management in libltdl with `lt_dlinsertsearchdir'
call.
* Support /lib/w32api in recent cygwin releases.
* Support cross compilation to mingw.
* Support for .rc files (Windows resource compiler).
* Improved handling of mingw gcc.
* Improved handling of $PATH with entries containing spaces.
* Improved support for linking with gcc on aix4* and aix5*.
* Improved support for GCC 3.0.
* Initial support for QNX RTOS, UnixWare 7 and OpenUNIX 8.
* Bug fixes to the OpenBSD port.
* Bug fixes.

Thanks to all those who contributed!

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Problems with AIX4 Compiler

[Robert Boehne]

Bill:

The problem isn't that the executables can't execute, it's
that they can't find the libraries that they depend on.
Because you're using MPI and mpicc, those libraries
are not in the default search path.  There are fixes for
your problem (if I recall correctly) in the current cvs
sources for libtool.  You can run your programs by setting
LIBPATH to the proper location of libmpi.a until you upgrade
Libtool.

HTH,

Robert

Bill Wendling wrote:
 
 Hello,
 
 I have a question/problem with libtool and autoconf which I was hoping
 someone here could help me with.
 
 We've had this problem with earlier versions of libtool and autoconf and
 I'm trying libtool-1.4.2 and autoconf-2.52 for our project. When working
 on the SP3 machines (config.guess output: rs6000-ibm-aix4.3.3.0, and the
 other being powerpc-ibm-aix4.3.3.0), the compiler would output binaries
 which can't execute. That is, there's a problem during linking.
 
 During linking, -Wl,-b -Wl,libpath:... flags get appended to the
 compile line and cause the compiler (C for AIX Compiler, Version 5.0.2.0)
 to produce code which can't execute.
 
 Here's the errors we see (the result of running it through the libtool
 --mode=execute commands)
 
 rm -f .libs/H5detectS.c .libs/H5detect.nm .libs/H5detect.nmS
 .libs/H5detect.nmT
 mpicc .libs/H5detectS.o -o H5detect H5detect.o  -lm  -Wl,-bnolibpath
 -Wl,-blibpath:/g/g21/wendling/v1.4/bin:/usr/lib:/lib
 rm -f .libs/H5detectS.o
 LD_LIBRARY_PATH=$LD_LIBRARY_PATH`echo  | \
 sed -e 's/-L/:/g' -e 's/ //g'`  ../libtool --mode=execute 
./H5detect H5Tinit.c
 exec(): 0509-036 Cannot load program ./H5detect because of the following
 errors:0509-150   Dependent module libmpi.a(mpipoe.o) could not be loaded.
 0509-022 Cannot load module libmpi.a(mpipoe.o).
 0509-026 System error: A file or directory in the path name does not exist.
 
 Have you seen this before? Is there a fix for it?
 
 Thanks you.
 
 (P.S., please include my email address in your replies as I'm not
 subscribed to this list).
 


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Script errors in libtool on Darwin

[Robert Boehne]

Timothy J. Wood wrote:
 
Oh please.  Give me a little credit :)
 
'head' certainly is installed.
 
The problem is that head is getting passed a bogus empty argument
 because $expore_symbols isn't set yet.  Thus, the 'head' command
 embedded in the script below is getting called when it is parsed rather
 than being considered quoted.
 
You can tell this is the case by the pair of colons after the 'head'
 in the error.  The filename is supposed to go before the second colon.
 
 -tim
 

OK, in that case you should report the bug to gcc.  They have their
own
version of libtool that are mostly based on our (defunct)
multi-language-branch.
OR, if you wanted to get ballsy, you could get current CVS Libtool
and use that instead.

HTH,

Robert

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool CVS permanently broken?

[Robert Boehne]

Bob Friesenhahn wrote:
 
 I assume that libtool is currently a dead project since libtool CVS
 has not been updated in weeks, but could the contents of CVS at least
 be left in a functional state before allowing libtool to die?
 
 Bob
 ==
 Bob Friesenhahn
 [EMAIL PROTECTED]
 http://www.simplesystems.org/users/bfriesen
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

I use it every day.  It hasn't had any checkins for awhile because
it works so well.  Are you trying to report a bug? (note, extreme
sarchasm ;)

- Rob

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: problem with the length of @mibgroup_list_lo@

[Robert Boehne]

Nima Malekmanesh wrote:
 
 Hi:
   I'm running into a problem during my make configure process.  After my
 make configure process is complete, the value of @mibgroup_list_lo@ is left
 blank in my Makefiles.  This problem appears as the size of
 @mibgroup_list_lo@ increases to a specific size.  I've checked the status of
 this variable in configure.status and everything seems to be ok, I can't
 figure out where in the configure process this variable is being lost? i've
 echoed the value of @mibgroup_list_lo@ at every stage of the configure file
 and the contents of it are present.  Anyone have any suggestions on where
 the contents of @mibgroup_list_lo@ is being lost?
 
 thanks,
 Nima

This isn't a Libtool problem, the @name@ syntax is used by Autoconf
generated
configure scripts to substitute values into Makefiles.  The problem is
probably
with the package you're configuring, so you should contact them.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

conftest directory problems

[Robert Boehne]

checking dynamic linker characteristics... GNU/Linux ld.so
checking for ANSI C header files... rm: conftest: is a directory
rm: conftest: is a directory
rm: conftest: is a directory
rm: conftest: is a directory
no
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... rm: conftest: is a directory
rm: conftest: is a directory
no
checking which extension is used for shared libraries...
/icarus/GNU/libtool/libltdl/configure: conftest: Is a directory
cat: conftest: Invalid argument
rm: conftest: is a directory

checking which variable specifies run-time library path...
LD_LIBRARY_PATH
checking for the default library search path... /lib /usr/lib
checking for objdir... .libs
checking whether libtool supports -dlopen/-dlpreopen... no
checking for shl_load... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for shl_load in -ldld... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for dlopen in -ldl... rm: conftest: is a directory
rm: conftest: is a directory
no
rm: conftest: is a directory
checking for dlopen in -lsvld... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for dld_link in -ldld... rm: conftest: is a directory
rm: conftest: is a directory
no
rm: conftest: is a directory
checking for _ prefix in compiled symbols... rm: cannot remove directory
`conftest/out': Permission denied
rm: cannot unlink `conftest/conftest.java': Permission denied
rm: cannot remove directory `conftest': Directory not empty
no
checking whether deplibs are loaded by dlopen... yes
checking for argz.h... yes
checking for error_t... yes
checking for argz_append... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for argz_create_sep... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for argz_insert... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for argz_next... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for argz_stringify... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for assert.h... yes
checking for ctype.h... yes
checking for errno.h... yes
checking for malloc.h... yes
checking for memory.h... yes
checking for stdlib.h... yes
checking for stdio.h... yes
checking for unistd.h... yes
checking for dl.h... no
checking for sys/dl.h... no
checking for dld.h... no
checking for string.h... yes
checking for strchr... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for index... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for strrchr... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for rindex... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for memcpy... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for bcopy... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for memmove... rm: conftest: is a directory
rm: conftest: is a directory
no
checking for strcmp... rm: conftest: is a directory
rm: conftest: is a directory
no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
rm: cannot remove directory `conftest/out': Permission denied
rm: cannot unlink `conftest/conftest.java': Permission denied
rm: cannot remove directory `conftest': Directory not empty
rm: cannot remove directory `conftest/out': Permission denied
rm: cannot unlink `conftest/conftest.java': Permission denied
rm: cannot remove directory `conftest': Directory not empty

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Patch #41] Do all rm's in one command with --mode=clean

[Robert Boehne]

Jeff Dubrule wrote:
 
 On Wed, Oct 24, 2001 at 09:21:48AM -0500, Robert Boehne wrote:
 
  Libtool saves a good guess for the maximum length
  of command lines as max_cmd_len so if you wanted to
  support removing files up to an average of 99 characters
  you could divide max_cmd_len by 100 to get the number
  of files to delete at a time.
 
 Ah...  This is new (i.e. later than the version I was patching, 1.4.2)
 
  Hope that helps,
 
 Ayup.  I submitted a new patch to savannah.
 

Jeff:

This is closer, but the max_cmd_len isn't 1/4, it is 3/4.
If you get too close to the limit you could occasionally pass
expr an argument list that was greater than the system would
allow.  If that happens with this code it will be treated
as if the command was short enough to execute (rm'ing nothing).
Two fixes would be to make sure expr succeeds (same as when
doing piecewise shared object linking) or you could just
test against some fraction of max_cmd_len (1/2 or 1/4) just
to make sure you don't run over the limit very often.

+  # $max_cmd_len is actually 1/4 of the max command length, 
+  # so if we go a little over, it's OK...
+  if test `expr X$rmfiles : .*` -gt $max_cmd_len; then
+$show $rm $rmfiles
+$run $rm $rmfiles || exit_status=1
+   rmfiles=
+  fi
+done

Are you having fun yet?  These little details really dealt
me fits when I wrote the piecewise linking code.  One more try
should get it.

Keep up the good work,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Problems with AIX4 Compiler

[Robert Boehne]

Bill:

The following code is what is currently used in libtool HEAD:
  _LT_AC_TAGVAR(hardcode_libdir_flag_spec,
$1)='${wl}-blibpath:$libdir:'$aix_libpath
The code you show looks to me like it is wrong, binder flags are
specified with -Wl,-bFLAG not -Wl,-b -Wl,FLAG.  It is doubtful that
this is a problem with the HEAD version, but could you try out the
head version and let us know if your problem is still there?
If so, send a detailed bug report so we can sort it out.

Thanks,

Robert


Bill Wendling wrote:
 
 Hi all,
 
 It's been awhile...we had a release and stuff and I couldn't get back to
 this problem until now.
 
 We're still having this problem even with the newest libtool and autoconf
 stuff...
 
 Also sprach [EMAIL PROTECTED]:
 } I have not seen a problem like that before.  But I don't think
 } libtool should be issuing link flags during the compile operation.
 }
 } I would try one of the newer versions of libtool. Version 1.4 has
 } many fixes for AIX, and we have a version of 1.3.5 at
 } http://www.ibm.com/servers/aix/products/aixos/linux/index.html
 } that also includes many of the same changes.
 }
 } Dan
 }
 }  From: Bill Wendling [EMAIL PROTECTED]
 }  To: [EMAIL PROTECTED]
 }  Subject: Problems with AIX4 Compiler
 } 
 }  Hello,
 } 
 }  I have a question/problem with libtool which I was hoping someone here
 }  could help me with.
 } 
 }  We are using ``libtool-1.3.4'' for our project. When working on the SP3
 }  machines (config.guess output: rs6000-ibm-aix4.3.3.0, and the other being
 }  powerpc-ibm-aix4.3.2.0), the compiler would output binaries which don't
 }  have the executable bit set. That is, there's a problem during the
 }  compile.
 } 
 }  We've tracked the problem down to the ``ltconfig'' file. Somewhere around
 }  line 1280, the line
 } 
 }  hardcode_libdir_flag_spec='${wl}-b ${wl}nolibpath ${wl}-b 
${wl}libpath:$libdir:/usr/lib:/lib'
 } 
 }  is being executed. The -Wl,-b -Wl,nolibpath -Wl,-b -Wl,libpath:...
 }  flags which get appended to the compile line is causing the compiler
 }  (C for AIX Compiler, Version 5.0.2.0) to produce the nonexecutable code.
 } 
 }  I know that libtool is now at verion 1.4, but I have reason to believe
 }  that the problem is still in there.
 } 
 }  Have you seen this before? Is there a fix for it? Right now, we have a
 }  very hacky fix (basically checking for the failing platforms and stopping
 }  the addition of the -Wl,... flags), but this fails for some machines
 }  which change their name from login to login.
 } 
 }  Thanks you.
 } 
 }  (P.S., please include my email address in your replies as I'm not
 }  subscribed to this list).
 } 
 }  --
 }  || Bill Wendling[EMAIL PROTECTED]
 }  || Coding Simian
 } 
 }  ___
 }  Libtool mailing list
 }  [EMAIL PROTECTED]
 }  http://mail.gnu.org/mailman/listinfo/libtool
 
 --
 || Bill Wendling[EMAIL PROTECTED]
 || Coding Simian
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Patch #41] Do all rm's in one command with --mode=clean

[Robert Boehne]

Jeff:

Heh, yeah, this is getting more complex isn't it.  :)
Libtool saves a good guess for the maximum length
of command lines as max_cmd_len so if you wanted to
support removing files up to an average of 99 characters
you could divide max_cmd_len by 100 to get the number
of files to delete at a time.  The max_cmd_len is meant
to be a safe lower bound, libtool doesn't count all the
arguments, only the object files, so

max_cmd_len  maximum length of object files listed + length of other
linking arguments

  Or we could get everyone to switch to the GNU Hurd OS,
that is the only one I know of that doesn't have limits
on the length of a command line. ;)

Hope that helps,

Robert

Jeff Dubrule wrote:
 
 Hmm.  I was having trouble trying to feed 'xargs' it's data without
 actually putting it all on a command-line at some point(silly, eh?).
 In any event, perhaps something like this will work:
 
for each file
   ...
   $rmfiles=$rmfiles $some_files_to_delete
   ...
   if 100  -l $rmfiles  then
 $show $rm $rmfiles
 $run $rm || exit_status=1
 $rmfiles=
   fi
 done
 if test -n $rmfiles; then
   $show $rm $rmfiles
   $run $rm || exit_status=1
   $rmfiles=
 fi
 
 Is there a less random number than 100, that would be a reasonable
 minimum?
 
 -jeff

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: linker doesn't like .lo files

[Robert Boehne]

[EMAIL PROTECTED] wrote:
 
 I'm trying to make libtool work on OS/390 to support shared library
 building and have run into an issue where the compiler won't accept .lo
 files to pass to the linker - it generates an error about an unaccepted
 file extension.  I'm wondering if there is already a mechanism in place for
 dealing with this.  I saw a note in ltmain.sh about linkers which dislike
 .lo files (aix specifically - though not true anymore apparently) but all
 this section of code did was link .o files to the .lo file - which is
 not really the correct behavior in the general sense since this could
 interfere with non-pic and pic objects.  It wasn't clear to me how the
 linker then got passed the .o files instead of the .lo ones.  Anyone
 have any clues on this?
 
 Tom.

Tom:

Libtool will take an invocation like
libtool gcc --mode=link foo.lo bar.lo ...
and translate this into the appropriate calls to ar, ld, nm etc.,
with actual object files (foo.o bar.o) passed to them.  The .lo
file contains text to show libtool where and what the real object
files are about.
I think the comments about AIX linker not liking .lo may be
a relic from the days when Libtool put actual object code in .lo files
and passed these to the linker.
In your case, the linker should be passed .o files, only libtool
should be passed .lo files.  In most cases, porting to a new OS
is a fairly simple excercise, add lines in libtool.m4 for your
particular architecture, run the test cases to see what works,
fix what you can, continue this until all tests pass then try
another compiler. ;)   You'll need to know how your system handles
libraries and run-time loading as well.  Check the manual for
more instruction on how to port Libtool.

Thanks,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: ar cru piecewise linking of same named objects

[Robert Boehne]

Kevin Ryde wrote:
 
 Robert Boehne [EMAIL PROTECTED] writes:
 
  Could you try changing AR_FLAGS in your libtool script
  to see if that works?
 
 AR_FLAGS=cq seems to work on all the systems I've tried, and fixes the
 ultrix problem.  As long as ranlib does its job then I imagine it'd
 have to work everywhere.
 

What's the Ultrix problem?

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4 not passing linker directives

[Robert Boehne]

Ian:

Automake uses Libtool to create libraries because it is portable,
it's practially the only thing that is.  One thing you should check,
do you really have to specify what is static?  I belive that under
Linux, the linker will choose shared libs over archives, if that
helps at all.  Perhaps you could train your app to find only
the archive libs at link time rather than add -Wl,Bstatic in
your link line.
Another alternative is to stop using Automake, just use the
Makefile.in that you already generated, and tailor it to
link with exactly the options you're hoping for.
  Did I miss anything?

HTH,

Rob

Ian Peters wrote:
 
 Well,
 
 I do realize that it's non-portable, but the number of platforms I'm
 building on is very restricted (the application is only of any real use
 on Linux systems running RPM, dpkg, and a few other special cases).  I'm
 not really intentionally trying to use libtool; I'm just using automake,
 which told me to pass linker directives in the prog_LDADD variable,
 which I did, until it broke, and it seems that libtool 1.4 is what
 changes this behaviour.
 
 I'm not sure why it's using libtool to link my program -- is this
 necessary, avoidable?
 
 Ian
 
 On Sat, 2001-10-06 at 17:15, Peter Eisentraut wrote:
  Ian Peters writes:
 
   Yes, the end goal is to have all of the libraries between the -Bstatic
   and -Bdynamic linked statically, while keeping a dynamic binary against
   libc and ld-linux.
 
  You do realize that this goal cannot be portably accomplished, so you
  perhaps shouldn't use libtool?
 
  --
  Peter Eisentraut   [EMAIL PROTECTED]   http://funkturm.homeip.net/~peter
 
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool