Re: Inter-library dependencies
On Sun, Oct 22, 2000 at 10:51:12AM -0600, Wesley W. Terpstra wrote: > All of what you have just described should already work under the newest libtool. I'll double check that it doesn't work with 1.3.5, then upgrade libtool to the latest cvs version and check again. First for 1.3.5 thus: > Try getting the version out of cvs and seeing if that solves your > problems. Also check that you are compiling with commands roughly like: > > libtool c++ -Wall -O2 -g -c cwd.c -o cwd.lo /bin/sh ./libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I- -I./include -I../libcw/src/libcwd/include -DDEBUG-g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -c ../libcw/src/libcwd/type_info.cc which executes: g++ -DHAVE_CONFIG_H -I. -I- -I./include -I../libcw/src/libcwd/include -DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -Wp,-MD,.deps/type_info.pp -c ../libcw/src/libcwd/type_info.cc -fPIC -DPIC -o type_info.lo That seems correct. > libtool c++ -Wall -O2 -g -rpath /usr/lib -o libcwd.la cwd.lo -ldl -lbfd /bin/sh ./libtool --mode=link g++ -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -o libcwd.la -rpath /usr/local/lib -version-info 99:4:99 bfd.lo debug.lo debugdebugcheckpoint.lo debugmalloc.lo demangle.lo printcw.lo strerrno.lo type_info.lo utils/libutils.la -lbfd -liberty -ldl which executes: gcc -shared bfd.lo debug.lo debugdebugcheckpoint.lo debugmalloc.lo demangle.lo printcw.lo strerrno.lo type_info.lo -Wl,--whole-archive utils/.libs/libutils.al -Wl,--no-whole-archive -lbfd -liberty -ldl -lc -Wl,-soname -Wl,libcwd.so.0 -o .libs/libcwd.so.0.99.4 I am afraid that -liberty got linked in: ~/c++/libcw-objdir/.libs>nm libcwd.so.0.99.4 | grep xmalloc 00036a30 T xmalloc 00036a20 T xmalloc_set_program_name while libiberty.a is a static library, not compiled with -fPIC. This is bad. For the rest it looks conceptually like your line. > libtool c++ -Wall -O2 -g -c cw.c -o cw.lo /bin/sh ./libtool --mode=compile g++ -I. -I- -I./include -I../../../libcw/src/libcw/include-DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -c version.cc which executes: g++ -I. -I- -I./include -I../../../libcw/src/libcw/include -DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -Wp,-MD,.deps/version.pp -c version.cc -fPIC -DPIC -o version.lo This is equivalent with the above > libtool c++ -Wall -O2 -g -rpath /usr/lib -o libcw.la cw.lo libcwd.la /bin/sh ./libtool --mode=link g++ -DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -o libcw.la -rpath /usr/local/lib -version-info 0:0:0 version.lo crosslink/libcrosslink.la io/libio.la kernel/libkernel.la llists/libllists.la net/libnet.la ../libcwd/libcwd.la which executes: libtool: link: error: cannot link shared libraries into libtool libraries Duh. Well, you said that it was supported in 1.4, not 1.3.5. > c++ -Wall -O2 -g -c mytest.c -o mytest.o > libtool c++ -Wall -O2 -g -o mytest mytest.o libcwd.la Surely you mean: libtool c++ -Wall -O2 -g -o mytest mytest.o libcw.la Note the libcwd.la -> libcw.la > PS. I've moved my reply from 'libtool-patch' to 'libtool' b/c there is no > patch under discussion. Ok. > Wesley W. Terpstra <[EMAIL PROTECTED]> > Javien Canada Inc. - Linux Developer Thanks, I'll follow up with the results under 1.4-to-be tomorrow. -- Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Inter-library dependencies
Hi,
I am stuck :/
Even after applying the patch at the bottom of README to my automake,
it still doesn't work:
~/c++/libcw>make
aclocal
autoheader
autoconf
make -C src/libcwd maintainer-startup
make[1]: Entering directory `/home/carlo/c++/libcw/src/libcwd'
cp /usr/src/libtool/install-prefix/share/libtool/config.guess .
cp /usr/src/libtool/install-prefix/share/libtool/config.sub .
cp /usr/src/libtool/install-prefix/share/libtool/ltmain.sh .
aclocal
autoheader
autoconf
cp /usr/share/automake/install-sh .
cp /usr/share/automake/missing .
cp /usr/share/automake/mkinstalldirs .
automake
make[1]: Leaving directory `/home/carlo/c++/libcw/src/libcwd'
cp -f src/libcwd/install-sh .
make -C src/libcw maintainer-startup
make[1]: Entering directory `/home/carlo/c++/libcw/src/libcw'
cp /usr/src/libtool/install-prefix/share/libtool/config.guess .
cp /usr/src/libtool/install-prefix/share/libtool/config.sub .
cp /usr/src/libtool/install-prefix/share/libtool/ltmain.sh .
ln -sf ../libcwd/maintMakefile.in
aclocal -I ../libcwd
autoheader
autoconf
cp /usr/share/automake/install-sh .
cp /usr/share/automake/missing .
cp /usr/share/automake/mkinstalldirs .
automake
make[1]: Leaving directory `/home/carlo/c++/libcw/src/libcw'
So far so good.
But then:
~/c++/libcw-objdir>rm -rf * .deps
~/c++/libcw-objdir>../libcw/configure --enable-maintainer-mode
creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for working aclocal... found
checking for working autoconf... found
checking for rm... /bin/rm
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
configuring in src/libcwd
running /bin/sh ../../../libcw/src/libcwd/configure --enable-maintainer-mode
--cache-file=../.././config.cache --srcdir=../../../libcw/src/libcwd
loading cache ../.././config.cache
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking host system type... i686-pc-linux-gnu
checking for g++... g++
checking whether the C++ compiler (g++ ) works... yes
checking whether the C++ compiler (g++ ) is a cross-compiler... no
checking whether we are using GNU C++ version 2.95.1 or later... yes
checking how to run the C++ preprocessor... g++ -E
checking if we can use cached results for the tests... no
checking if the compiler understands -pipe... yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether make sets ${MAKE}... yes
checking for gawk... gawk
checking for ps... /bin/ps
checking build system type... i686-pc-linux-gnu
checking for ranlib... ranlib
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 for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ../.././config.cache
../../../libcw/src/libcwd/ltconfig: ../../../libcw/src/libcwd/ltconfig: No such file
or directory
configure: error: libtool configure failed
configure: error: ../../../libcw/src/libcwd/configure failed for src/libcwd
It seems that just the patch at the bottom of README isn't enough(?).
The generated `configure' still tries to execute a ltconfig.
What do I do wrong?
--
Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=-
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Inter-library dependencies
On Mon, Oct 23, 2000 at 09:29:17AM -0600, Wesley W. Terpstra wrote:
> > ../../../libcw/src/libcwd/ltconfig: ../../../libcw/src/libcwd/ltconfig: No such
>file or directory
> > configure: error: libtool configure failed
>
> You shouldn't need ltconfig... After installing the cvs libtool, run
> libtoolize in your source dir. That should provide you with config.guess,
> config.sub, and ltmain.sh. Then add AM_PROG_LIBTOOL to your configure.in
> and copy libtool.m4 to aclocal.m4. Run autoconf && ./configure. Then you
> should have a libtool.
The problem was indeed that the wrong libtool.m4 was used.
However, isn't that a flaw in the design? Why doesn't automake/libtool
support installation in different prefix directories?
What is going wrong is this:
If I install automake with prefix /usr, and libtool with
prefix /usr/local, then automake has the following lines
in its `aclocal' script:
$prefix = "/usr";
...
$acdir = "${prefix}/share/aclocal";
...
&scan_m4_files ($acdir, @dirlist);
Completely missing any notition of the libtool.m4 file
in /usr/local/share/aclocal. Adding that directory
to `@dirlist' also doesn't help when there is an old
version of libtool installed in /usr: then you get
duplicated macros errors.
The best solution that I can think of is to give
macros loaded from $acdir a `weak' linkage: if macros
are defined in a directory specified with -I on the
command line, then this should not lead to duplicated
macro errors imho.
As a work around, I will install automake and autoconf
twice (I need two versions of libtool to be installed).
--
Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=-
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Inter-library dependencies
On Tue, Oct 24, 2000 at 02:32:24PM -0200, Alexandre Oliva wrote: > On Oct 24, 2000, Carlo Wood <[EMAIL PROTECTED]> wrote: > > > Completely missing any notition of the libtool.m4 file > > in /usr/local/share/aclocal. > > See the libtool manual. It advises you to copy libtool.m4 into > acinclude.m4 or aclocal.m4, precisely to avoid this kind of problem. That wasn't the point. The above quote is out of context, it is a remark about what happens in the explicit case that I gave above it. The rest of the mail addressed possible workarounds including a variant of your suggestion and why that doesn't work. I copied libtool.m4 to the end of acinclude.m4 to get: *** Generating files in the src/libcw aclocal: ../libcwd/acinclude.m4: 864: duplicated macro `AC_PROG_LIBTOOL' aclocal: ../libcwd/acinclude.m4: 878: duplicated macro `AC_LIBTOOL_SETUP' aclocal: ../libcwd/acinclude.m4: 3458: duplicated macro `AC_LIBTOOL_DLOPEN' aclocal: ../libcwd/acinclude.m4: 3461: duplicated macro `AC_LIBTOOL_WIN32_DLL' aclocal: ../libcwd/acinclude.m4: 3467: duplicated macro `AC_ENABLE_SHARED' aclocal: ../libcwd/acinclude.m4: 3493: duplicated macro `AC_DISABLE_SHARED' aclocal: ../libcwd/acinclude.m4: 3500: duplicated macro `AC_ENABLE_STATIC' aclocal: ../libcwd/acinclude.m4: 3526: duplicated macro `AC_DISABLE_STATIC' aclocal: ../libcwd/acinclude.m4: 3534: duplicated macro `AC_ENABLE_FAST_INSTALL' aclocal: ../libcwd/acinclude.m4: 3560: duplicated macro `AC_DISABLE_FAST_INSTALL' aclocal: ../libcwd/acinclude.m4: 3648: duplicated macro `AC_PROG_LD' aclocal: ../libcwd/acinclude.m4: 3722: duplicated macro `AC_PROG_LD_GNU' aclocal: ../libcwd/acinclude.m4: 3885: duplicated macro `AC_PROG_NM' aclocal: ../libcwd/acinclude.m4: 3921: duplicated macro `AC_CHECK_LIBM' aclocal: ../libcwd/acinclude.m4: 3948: duplicated macro `AC_LIBLTDL_CONVENIENCE' aclocal: ../libcwd/acinclude.m4: 3969: duplicated macro `AC_LIBLTDL_INSTALLABLE' aclocal: ../libcwd/acinclude.m4: 3990: duplicated macro `AM_PROG_LIBTOOL' aclocal: ../libcwd/acinclude.m4: 3991: duplicated macro `AM_ENABLE_SHARED' aclocal: ../libcwd/acinclude.m4: 3992: duplicated macro `AM_ENABLE_STATIC' aclocal: ../libcwd/acinclude.m4: 3993: duplicated macro `AM_DISABLE_SHARED' aclocal: ../libcwd/acinclude.m4: 3994: duplicated macro `AM_DISABLE_STATIC' aclocal: ../libcwd/acinclude.m4: 3995: duplicated macro `AM_PROG_LD' aclocal: ../libcwd/acinclude.m4: 3996: duplicated macro `AM_PROG_NM' As I said in my previous mail, I need two versions of libtool to be installed on my system. But ok, since the problem is with automake and not with libtool, it doesn't make much sense to discuss this. -- Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Conflict between autoconf and libtool way of handling libraries
autoconf handles libraries as if libtool doesn't exist: ./configure figures out which libraries are needed and LIBS is set accordingly in *all* generated Makefiles. The idea of this is that libraries that are needed are needed everywhere, also when compiling tests. [ Meaning: if libfoo needs libbfd, then libfoo is compiled with -lbfd, and tests are compiled with -lfoo -lbfd. ] However, when building a library yourself with libtool that uses libraries on its own then the libraries needed by the library that is being build should not be passed on to the tests that link with the built library. For example, in my case: 1) I build libcwd.la (which depends on -lbfd -liberty) 2) I build libcw.la which depends on ../libcwd/libcwd.la next I want to compile a test program that depends on libcw.la and it gets linked with ../libcwd/libcwd.la too because LIBS was set to `../libcwd/libcwd.la' during the configuration of libcw! That does not only fail because the relative path is nonsense in the test directory, it is also essentially wrong because the dependency on libcwd is supposed to be passed by libtool, not by autoconf (by means of "passing on" the LIBS environment variable). [ I get: ~/c++/libcw-objdir/src/libcw/io/tests>make burst_tst g++ -DHAVE_CONFIG_H -I- -I../../include -I../../../../../libcw/src/libcw/io/tests/../../include-DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -c ../../../../../libcw/src/libcw/io/tests/burst_tst.cc /bin/sh ../../libtool --mode=link g++ -DDEBUG -g -fno-exceptions -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -o burst_tst burst_tst.o ../../libcw.la ../libcwd/libcwd.la mkdir .libs libtool: link: cannot find the library `../libcwd/libcwd.la' Where "../libcwd/libcwd.la" shouldn't be there at all (it is the LIBS that was needed to build libcw in ~/c++/libcw-objdir/src/libcw). ] The only work-around seems to be to put a new configure.in file in every test directory I have, and thus a lot more files :/. This is hardly acceptable because that would increase the size of the tarball dramatically (a `configure' script is LARGE). There must be better way, I hope. -- Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool --version ?
Any reason that `libtool --version' doesn't work anymore with the current CVS version? It breaks a script of me that I use(d) to determine which version of libtool people are using. If it is deliberately removed, then is it garanteed that `libtoolize --version' will keep working? Thanks, -- Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Nevermind
Ok, nevermind. The workaround for the infinite configure loop that occured with ealier versions (which now seems fixed) caused an empty ltmain.sh file now (to be installed). I removed my own patch and it works again. On Mon, Nov 13, 2000 at 12:45:49PM +0100, Carlo Wood wrote: > Any reason that `libtool --version' doesn't work anymore with the > current CVS version? It breaks a script of me that I use(d) to > determine which version of libtool people are using. > > If it is deliberately removed, then is it garanteed that > `libtoolize --version' will keep working? -- Carlo Wood <[EMAIL PROTECTED]>-=- Jesus Loves you -=- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Conflict between autoconf and libtool way of handling libraries (try 2)
Hi again, nobody addressed the mail that I wrote a month ago, included again below, it is still a problem for me however. What is the right way of doing this? Or is indeed something that is actually a problem with libtool? On Thu, Oct 26, 2000 at 03:31:04PM +0200, Carlo Wood wrote: > autoconf handles libraries as if libtool doesn't exist: > ./configure figures out which libraries are needed and > LIBS is set accordingly in *all* generated Makefiles. > > The idea behind this is that libraries that are needed are > needed everywhere: also when compiling tests. > > [ Meaning: if libfoo needs libbfd, then libfoo is > compiled with -lbfd, and tests are compiled with > -lfoo -lbfd. ] > > However, when building a library yourself with libtool > that uses libraries on its own then the libraries needed > by the library that is being build should not be passed > on to the tests that link with the built library. > > For example, in my case: > 1) I build libcwd.la (which depends on -lbfd -liberty) > 2) I build libcw.la which depends on ../libcwd/libcwd.la > > next I want to compile a test program that depends on > libcw.la and it gets linked with ../libcwd/libcwd.la too > because LIBS was set to `../libcwd/libcwd.la' during the > configuration of libcw! > > That does not only fail (because the relative path is nonsense > in the test directory) it is also essentially wrong because > the dependency on libcwd is supposed to be passed by libtool, > not by autoconf (by means of "passing on" the LIBS environment > variable). > > [ I get: > > ~/c++/libcw-objdir/src/libcw/io/tests>make burst_tst > g++ -DHAVE_CONFIG_H -I- -I../../include >-I../../../../../libcw/src/libcw/io/tests/../../include-DDEBUG -g -fno-exceptions >-pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings >-Werror -c ../../../../../libcw/src/libcw/io/tests/burst_tst.cc > /bin/sh ../../libtool --mode=link g++ -DDEBUG -g -fno-exceptions -pipe -Wall >-Woverloaded-virtual -Wundef -Wpointer-arith -Winline -Wwrite-strings -Werror -o >burst_tst burst_tst.o ../../libcw.la ../libcwd/libcwd.la > mkdir .libs > libtool: link: cannot find the library `../libcwd/libcwd.la' > > Where "../libcwd/libcwd.la" shouldn't be there at all > (it is the LIBS that was needed to build libcw in > ~/c++/libcw-objdir/src/libcw). > ] > > The only work-around seems to be to put a new configure.in file in every > test directory. This is hardly acceptable because that would increase > the size of the tarball dramatically (a `configure' script is LARGE). > > There must be better way, I hope. > Please ask me to clarify when needed. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
How to build a .dll on cygwin?
Hi, I am trying several days now to build a .dll on cygwin. But it only wants to build a static library :(. What am I doing wrong? Here is what happens, this is supposed to create a dll: $ make libcw.la if /bin/bash ./libtool --mode=compile g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -Winline -MT libcw_la-version.lo -MD -MP -MF ".deps/libcw_la-version.Tpo" \ -c -o libcw_la-version.lo `test -f 'version.cc' || echo './'`version.cc; \ then mv -f ".deps/libcw_la-version.Tpo" ".deps/libcw_la-version.Plo"; \ else rm -f ".deps/libcw_la-version.Tpo"; exit 1; \ fi g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -Winline -MT libcw_la-version.lo -MD -MP -MF .deps/libcw_la-version.Tpo -c version.cc -DPIC -o .libs/libcw_la-version.o [ comment: the above is correctly creating a pic-object; after all - we are trying to create a dll. Note that this results in the following lines in the created libcw_la-version.lo file: pic_object='.libs/libcw_la-version.o' non_pic_object=none ] /bin/bash ./libtool --mode=link g++ -o libcw.la -rpath /usr/local/lib -version-info 0:0:0 libcw_la-version.lo llists/libllists.la crosslink/libcrosslink.la io/libio.la kernel/libkernel.la net/libnet.la [ comment: this seems correct too no? .la as output, .lo and .la as input ] libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries [ What is this? Of course I have undefined symbols: the ones of libc and libstdc++ ?! ] rm -fr .libs/libcw.a .libs/libcw.la .libs/libcw.lai rm -fr .libs/libcw.lax mkdir .libs/libcw.lax rm -fr .libs/libcw.lax/libllists.a mkdir .libs/libcw.lax/libllists.a (cd .libs/libcw.lax/libllists.a && ar x /usr/src/libcw/llists/.libs/libllists.a) rm -fr .libs/libcw.lax/libcrosslink.a mkdir .libs/libcw.lax/libcrosslink.a (cd .libs/libcw.lax/libcrosslink.a && ar x /usr/src/libcw/crosslink/.libs/libcrosslink.a) rm -fr .libs/libcw.lax/libio.a mkdir .libs/libcw.lax/libio.a (cd .libs/libcw.lax/libio.a && ar x /usr/src/libcw/io/.libs/libio.a) rm -fr .libs/libcw.lax/libkernel.a mkdir .libs/libcw.lax/libkernel.a (cd .libs/libcw.lax/libkernel.a && ar x /usr/src/libcw/kernel/.libs/libkernel.a) rm -fr .libs/libcw.lax/libnet.a mkdir .libs/libcw.lax/libnet.a (cd .libs/libcw.lax/libnet.a && ar x /usr/src/libcw/net/.libs/libnet.a) ar cru .libs/libcw.a .libs/libcw.lax/libllists.a/cbll.o .libs/libcw.lax/libllists.a/expire.o .libs/libcw.lax/libllists.a/sbll.o .libs/libcw.lax/libcrosslink.a/crosslink.o .libs/libcw.lax/libio.a/dbstreambuf.o .libs/libcw.lax/libio.a/file.o .libs/libcw.lax/libio.a/pipe.o .libs/libcw.lax/libio.a/sock.o .libs/libcw.lax/libio.a/traits.o .libs/libcw.lax/libkernel.a/debugdaemon.o .libs/libcw.lax/libkernel.a/events.o .libs/libcw.lax/libkernel.a/execve.o .libs/libcw.lax/libkernel.a/GlobalObjectManager.o .libs/libcw.lax/libkernel.a/libcw_app.o .libs/libcw.lax/libkernel.a/memleak.o .libs/libcw.lax/libkernel.a/ostream_operators.o .libs/libcw.lax/libkernel.a/select.o .libs/libcw.lax/libkernel.a/signals.o .libs/libcw.lax/libkernel.a/support.o .libs/libcw.lax/libkernel.a/timing.o .libs/libcw.lax/libnet.a/inet_support.o ranlib .libs/libcw.a rm -fr .libs/libcw.lax creating libcw.la (cd .libs && rm -f libcw.la && ln -s ../libcw.la libcw.la) Ok, I am totally lost ... Why does it suddenly create a .libs/libcw.a ? Where is the .dll? Also, this *.a is not usable because the libcw_la-version.lo is NOT linked in: that only refers to a pic-object, not a non-pic-object. The result is a useless (broken) static library. Can someone please tell me what I am doing wrong? I suppose you need more info, but I don't know what :) -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: How to build a .dll on cygwin?
On Thu, Jul 01, 2004 at 06:50:38PM -0500, Bob Friesenhahn wrote: > You need to add -no-undefined to the libtool options. Thanks! This solved my problem! Nevertheless, it reveals a problem/bug in libtool. It should not have been necessary that I lost a few days with this: the warning message that libtool gives about undefined symbols wasn't clear enough for me. On top of that, the fact that libtool continued to assemble a static archive WITHOUT all objects (because some *.lo files were already compiled as pic_object) is clearly an error. The resulting .a archive is not usable. It would be better to turn this warning into a fatal error on cygwin and to add a remark about the correct usage of -no-undefined on windows. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Convenieve libraries and applications.
I have a normal application (not a shared library thus) which uses convenience libraries in subdirectories. This application also uses libltdl - in order to load modules. These modules needs to resolve symbols from the application, symbols that are in fact in the convenience libraries. The application itself doesn't use these symbols. As a result - the symbols are not put into the application! And loading the modules fails (or at least, calling the missing functions fails). What is needed here is obvious: I need to link the application with the --whole-archive/--no-whole-archive linker flags around the convenience libraries. But, libtool doesn't let me do that :/ It doesn't add it by itself, because I am not building a shared library but an application (using stuff like "-dlopen" self also doesn't help). And when I add the flags myself, like: myapp_LDFLAGS = -Wl,--whole-archive utils/libutils.la -Wl,--no-whole-archive then libtool rearranges the flags so that they come out as: -Wl,--whole-archive -Wl,--no-whole-archive obj1.o obj2.o ... utils/libutils.la and that doesn't do what I want. When I only use -Wl,--whole-archive and leave the -Wl,--no-whole-archive then something horrible gets wrong that simply is not an option. Can someone help me out please? -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenieve libraries and applications.
On Wed, Aug 11, 2004 at 05:49:29PM -0700, Howard Chu wrote: > I think this is what the -export-dynamic flag is for. If that is true, then it is broken. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenieve libraries and applications.
On Wed, Aug 11, 2004 at 06:00:00PM -0700, Jacob Meuser wrote: > On Wed, Aug 11, 2004 at 05:49:29PM -0700, Howard Chu wrote: > > I think this is what the -export-dynamic flag is for. > > I do believe that exports symbols from a shared lib. He has static libs. > > whole_archive_flag_spec is the variable in libtool to look at, but > that's about all I know about it. whole_archive_flag_spec is a libtool internal variable that specifies to libtool how to import all symbols in a convenience library; however - that is never even looked at when you are linking an application - only when you are creating a shared library. I think this is a bug, because clearly an application that dlopen's other libraries is no different from shared libraries in this regard: you want all symbols to be export just as well. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convenience libraries and applications.
On Thu, Aug 12, 2004 at 12:09:10PM +0900, Peter O'Gorman wrote: > -export-dynamic is to export symbols from an application so that they are > available to runtime loaded code. > > GNU libtool convenience libraries are, as far as I know, only designed to > use the whole archive when they are used in creating shared libraries. They > are built using position independent code for that purpose. While you can > use them when building applications, that is not their purpose. Then how should one build an executable that exists of source files spread over multiple directories? I thought I even saw examples that use convenience libs for that casse, though I could be wrong. Did I miss something in the documentation of libtool? > There is no way to do what you want, at the moment, using libtool (to my > knowledge). "convenience" libraries are just treated as ordinary libraries > when creating an executable. I suggest that you reference the symbols in > the executable so that your linker will keep them around. If you want to > add this feature to libtool (it sounds like it may be useful)... send > patches. I think it is clear by now (from this thread) that this is actually a needed but missing feature in libtool, so it should be added. However, I am a C++ coder - not a shell script coder; someone else with knowledge of the internals of libtool can do this job a lot more efficiently. Also take into account that that doesn't mean that I am sitting on the beach while that other person is fixing this; I work my ass off around the clock on Open Source, just different packages. Thanks, -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.8 on Solaris 8
On Thu, Aug 26, 2004 at 04:22:26PM -0400, Carlos Fangmeier wrote: > > Hi everyone, for a few weeks I'm working with autoconf and libtool to > build some libraries and application. I'm having some problem final > linking of the executable, the out is following: > > /bin/sh ../libtool --mode=link --tag=CXX g++ -g -O2 -o audio_ivr > -L/home/carlos/IVR_Base/src/snmp/.libs > -L/home/carlos/IVR_Base/src/socket/.libs > -L/home/carlos/IVR_Base/src/tiempo/.libs > -L/home/carlos/IVR_Base/src/conf/.libs > -L/home/carlos/IVR_Base/src/debug/.libs > -L/home/carlos/IVR_Base/src/vxml/.libs -L/usr/local/ssl/lib > -L/opt/nms/lib AudioChannel.o AudioConf.o audio_adm.o audio_appl.o > audio_ctrl.o audio_error.o audio_main.o audio_teln.o -lsnmp -lsckmsg > -ltiempo -lconf -ldebug -lvxml -lnetsnmp -lgen -lcrypto -lkstat -lelf > -lm -lnsl -lsocket -ladm -lpthread -lwwwinit -lwwwhtml -lwwwhttp > -lwwwcache -lwwwstream -lwwwapp -lwwwcore -lwwwutils -lwwwmime -lpics > -lwwwnews -lwwwdir -lwwwgopher -lwwwfile -lwwwftp -lwwwxml -lwwwtrans > -lmd5 -lwwwtelnet -lxmlparse -lxmltok -lcta -ladiapi -lnccapi -lvceapi > -lswiapi -ladidtm -ldl -lsocket Note that this doesn't look 'right', instead of having a lot of -L/.libs, you should be linking with the uninstalled .la file. This can be done by specifying the .la files in Makefile.am on the LIBADD line. > g++ -g -O2 -o .libs/audio_ivr AudioChannel.o AudioConf.o audio_adm.o > audio_appl.o audio_ctrl.o audio_error.o audio_main.o audio_teln.o > -L/home/carlos/IVR_Base/src/snmp/.libs [..snip..] > /usr/local/lib/./libstdc++.so /usr/local/lib/libnetsnmp.so -lgen -lcrypto [..snip..] > -Wl,/home/carlos/IVR_Base/lib -Wl,-R -Wl,/usr/local/lib -Wl,-R > -Wl,/usr/local/lib/. > ld: warning: file > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/../../libstdc++.so: linked > to /usr/local/lib/./libstdc++.so: attempted multiple inclusion of file Does the error message stop there? It doesn't seem finished. Note that /usr/local/lib/./libstdc++.so and /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/../../libstdc++.so are the same file. The explicit mentioning of /usr/local/lib/./libstdc++.so (just before the /usr/local/lib/libnetsnmp.so -lgen -lcrypto etc) is weird though. It might be that one of the libraries that you are using thinks that it needs it (is specifically asking for it). The first thing you should do is to find out which library thinks that it depends on /usr/local/lib/./libstdc++.so (if any). This dependency is probably one that is specified in an .la file of one of the libraries that you are linking with. And that is the real error here then. The crash might be cause by you linking to the wrong libstdc++.so. Is this the only "libstdc++.so*" on your system? -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
'dependency_libs' of .la file ignored?
This looks like a bug to me: On mingw, /bin/sh ../../libtool --mode=link --tag=CXX g++ -g -I/usr/src/install/3.2.3/include -I/usr/local/include -I/c/Progra~1/GnuWin32/include -L/usr/src/install/3.2.3/lib -L/usr/local/lib -L/c/Progra~1/GnuWin32/lib -o libxsltwrapp.la -rpath /usr/src/install/3.2.3/lib -L/usr/src/install/3.2.3/lib -L/usr/local/lib -L/c/Progra~1/GnuWin32/lib -version-info 5:0:5 -export-dynamic -no-undefined libxsltwrapp_la-init.lo libxsltwrapp_la-stylesheet.lo ../libxml/libxmlwrapp.la -lexslt rm -fr .libs/libxsltwrapp.dll.a g++ -shared -nostdlib c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/../../../dllcrt2.o c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/crtbegin.o .libs/libxsltwrapp_la-init.o .libs/libxsltwrapp_la-stylesheet.o -LC:/msys/1.0/local/lib -L/usr/src/install/3.2.3/lib -L/usr/local/lib -L/c/Progra~1/GnuWin32/lib ../libxml/.libs/libxmlwrapp.dll.a -lexslt -Lc:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3 -Lc:/mingw/bin/../lib/gcc-lib -L/mingw/lib/gcc-lib/mingw32/3.2.3 -Lc:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/../../.. -L/mingw/lib/gcc-lib/mingw32/3.2.3/../../.. -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/crtend.o -o .libs/libxsltwrapp-0.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libxsltwrapp.dll.a which results on undefined references because -lxslt is missing. I think that -lxslt should be there because it is in ../libxml/libxmlwrapp.la: dependency_libs=' -L/usr/src/install/3.2.3/lib -L/usr/local/lib -L/c/Progra~1/GnuWin32/lib -LC:/msys/1.0/local/lib -lxslt -lxml2 -lz -lm' Why does libtool not add the dependency_libs of a linked .la to the parameters of the g++ command? -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: 'dependency_libs' of .la file ignored?
On Tue, Aug 31, 2004 at 09:21:31PM +0100, Gary V. Vaughan wrote: > libtool --version? $ libtool --version ltmain.sh (GNU libtool) 1.5.8 (1.1220.2.117 2004/08/04 14:12:05) cvs doesn't compile on mingw. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: 'dependency_libs' of .la file ignored?
On Tue, Aug 31, 2004 at 08:49:03PM -0500, Bob Friesenhahn wrote: > On Wed, 1 Sep 2004, Peter O'Gorman wrote: > > >>cvs doesn't compile on mingw. > >> > > > >This is by far the more interesting bug as there are unlikely to be any > >more releases on branch-1-5, how does it fail? > > Perhaps he is talking about CVS HEAD rather than branch-1-5? Failure > of HEAD to compile under mingw would not surprise me since Gary has > made significant changes to libltdl code and it probably has not been > re-tested under WIN32. Yes its HEAD - and the failure is early, in the libltdl code. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: 'dependency_libs' of .la file ignored?
On Wed, Sep 01, 2004 at 08:35:43AM +0900, Peter O'Gorman wrote: > Carlo Wood wrote: > > >On Tue, Aug 31, 2004 at 09:21:31PM +0100, Gary V. Vaughan wrote: > > > >>libtool --version? > > > > > >$ libtool --version > >ltmain.sh (GNU libtool) 1.5.8 (1.1220.2.117 2004/08/04 14:12:05) > > That's pretty strange, I guess 'make check' in libtool fails everywhere too? Damn, you should have warned me this would take several hours to run! :/ So far no failures. Carlo [EMAIL PROTECTED] /usr/src/autotools/libtool-1.5.8 $ make check Making check in . make[1]: Entering directory `/usr/src/autotools/libtool-1.5.8' make[1]: Nothing to be done for `check-am'. make[1]: Leaving directory `/usr/src/autotools/libtool-1.5.8' Making check in libltdl make[1]: Entering directory `/usr/src/autotools/libtool-1.5.8/libltdl' make[1]: Leaving directory `/usr/src/autotools/libtool-1.5.8/libltdl' Making check in doc make[1]: Entering directory `/usr/src/autotools/libtool-1.5.8/doc' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/usr/src/autotools/libtool-1.5.8/doc' Making check in tests make[1]: Entering directory `/usr/src/autotools/libtool-1.5.8/tests' make check-TESTS make[2]: Entering directory `/usr/src/autotools/libtool-1.5.8/tests' PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: dryrun.test PASS: demo-nofast.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: demo-pic.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-nopic.test PASS: demo-make.test PASS: demo-exec.test PASS: depdemo-nofast.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test ... But now its 4:07 am and I have to go to bed. I'll let you know if anything failed later on, tomorrow. What if nothing fails? Can you explain why the dependencies get ignored? -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool chooses static version of library instead of dynamic?
On Sat, Sep 25, 2004 at 01:12:58PM +0400, Maarten Boekhold wrote: > Hi, > > Under cygwin I have a Makefile.am that generates a 'libtool --mode=link' > line that has references to libraries in it like > "../libs/libxffm_calls.la". When gcc is invoked, this is translated into > "../libs/.libs/libxffm_calls.dll.a", i.e. libtool chooses the *static* > version of the library to link against. That is correct. A .dll.a is a .a and therefore 'static' but it is also very small: it only contains stubs that will call the real functions in the .dll. The .dll.a is 100% equivalent to the .lib file that you'd be linking with under windows (and could link with using gcc (on cygwin/mingw32) except that libtool needs the extension .dll.a in order to recognize it. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Request to mailing list Lesstif rejected
On Mon, Oct 04, 2004 at 02:19:20AM -0400, [EMAIL PROTECTED] wrote: > Your request to the Lesstif mailing list > > Posting of your message titled "Encrypted document" > > has been rejected by the list moderator. The moderator gave the > following reason for rejecting your request: > > "Non-members are not allowed to post messages to this list." > > Any questions or comments should be directed to the list administrator > at: > > [EMAIL PROTECTED] Would the list moderator be so kind not to reply this type of rejection messages to the entire [EMAIL PROTECTED] list? Just sending it to the person who sent the original message seems enough (which wasn't me). I can imagine that this happens because someone is sending a post to [EMAIL PROTECTED] and CC-ing [EMAIL PROTECTED], then someone else replies to that who is member of [EMAIL PROTECTED] but not [EMAIL PROTECTED] and then the moderator of lesstif replies to everyone (including the CC-ed [EMAIL PROTECTED]) with a rejection. The solution would be to just reply to the address in the 'From:' line (ignoring the 'Reply-To: line) etc. -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Request to mailing list Lesstif rejected
I still say this is an error that needs to be fixed. It is not normal that one list sends bounces of spammers (or who-ever) to another list. Can't you just add a rule to your spam checker (which I see you have in the headers) for this? Either the lesstif list should stop bouncing to [EMAIL PROTECTED] or the libtool list should stop forwarding bounces. It is easy enough to detect that it concerns a bounce. Sorry to CC the list, but I did not see any reply for my previous posts that were sent only to the list admins. On Wed, Oct 06, 2004 at 02:22:51AM -0400, [EMAIL PROTECTED] wrote: > Your request to the Lesstif mailing list > > Posting of your message titled "Hidden message" > > has been rejected by the list moderator. The moderator gave the > following reason for rejecting your request: > > "Non-members are not allowed to post messages to this list." > > Any questions or comments should be directed to the list administrator > at: > > [EMAIL PROTECTED] > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool -- Carlo Wood <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
