Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
I'm curious. I thought I knew shell scripting and the basics of
automake but I don't know what 'fnord' is (or is it just a variable like
foo and/or bar). Perhaps as a consequence of that I don't know why
there is a need for a seperate LIBTOOL_BEGIN_COMPILE_CC and
LIBTOOL_END_COMPILE_CC macro (as opposed to a single LIBTOOL_COMPILE_CC
macro). Anyone willing to give me a brief explanation? I tried
googling for fnord but all I came up with is uses without any
explanation.
Steve Ellcey
Have you driven a fnord lately?
> From: Alexandre Oliva <[EMAIL PROTECTED]>
>
> LIBTOOL_BEGIN_COMPILE_CC = set fnord \
>
> LIBTOOL_END_COMPILE_CC = ; shift 1; \
> { test -d $$dir"/$(libtool_libdir) || \
> $(mkdir_p) "$$dir"/$(libtool_libdir); } && \
> rm -f "$$lofile"T "$$lofile" "$$dir/$$ofile" \
> "$$dir/$(libtool_libdir)/$$ofile" || : ; \
> $(LIBTOOL_COMPILE_CC_PIC) -o "$$dir/$(libtool_libdir)/$$ofile" \
> $${1+"$$@"} && \
> $(LIBTOOL_COMPILE_CC_NONPIC) -o "$$dir/$$ofile" $${1+"$$@"} && \
> { echo pic_object=$(LIBTOOL_PIC_OBJECT); \
> echo non_pic_object=$(LIBTOOL_NONPIC_OBJECT); } > "$$lofile"T && \
> mv "$$lofile"T "$$lofile"
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
linking with libexpat.so
I have a strange problem that is trivial to reproduce as shown here:
~/libtool# libtool --version
ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)
~/libtool# libtool --mode=link gcc -o test test.o -rpath /usr/lib -L/usr/lib -lpng
-lexpat
gcc -o .libs/test test.o -L/usr/lib -lpng /usr/lib/.libs/libexpat.so -Wl,--rpath
-Wl,/usr/lib
gcc: /usr/lib/.libs/libexpat.so: No such file or directory
Notice how the linker reference for the expat library has been rendered as
"/usr/lib//.libs/libexpat.so". Of course there is no such subdirectory as
"/usr/lib//.libs/". Yet the reference to libpng.so is simply -lpng as expected.
Both libexpat.so and libpng.so are installed in /usr/lib as shown here:
~/libtool# l /usr/lib/{libpng.so,libexpat.so}
lrwxrwxrwx1 root root 17 May 5 2003 /usr/lib/libexpat.so ->
libexpat.so.0.1.0*
lrwxrwxrwx1 root root 19 Nov 10 23:45 /usr/lib/libpng.so ->
libpng12.so.0.1.2.4*
I'm mentioning this problem because I've seen it come up on more than one occasion
when simply downloading and trying to build pretty common software. It happened again
today when I tried to build fontconfig-2.2.0. Before running off to the fontconfig
folks to ask about this I thought I'd try the small test, above.
Can you tell me what I can do to circumvent this problem? Do you think it's a
configuration anomaly on my system? I've been trying to find the answer in the rather
involved debug trace and config listing that I've attached below.
Thanks very much,
Bill
--
~/libtool# libtool --debug --mode=link gcc -o test test.o -rpath /usr/lib -L/usr/lib
-lpng -lexpat
+ test 10 -gt 0
+ arg=--mode=link
+ shift
++ echo X--mode=link
++ /usr/bin/sed -e '1s/^X//' -e 's/[-_a-zA-Z0-9]*=//'
+ optarg=link
+ test -n ''
+ mode=link
+ test 9 -gt 0
+ arg=gcc
+ shift
+ optarg=
+ test -n ''
+ nonopt=gcc
+ break
+ test -n ''
+ exec_cmd=
+ test -z ''
+ test -z link
+ test -n ''
+ generic_help=Try `libtool --help' for more information.
+ help=Try `libtool --help --mode=link' for more information.
+ modename=libtool: link
+ allow_undefined=yes
+ libtool_args=gcc
+ base_compile=gcc
+ compile_command=gcc
+ finalize_command=gcc
+ compile_rpath=
+ finalize_rpath=
+ compile_shlibpath=
+ finalize_shlibpath=
+ convenience=
+ old_convenience=
+ deplibs=
+ old_deplibs=
+ compiler_flags=
+ linker_flags=
+ dllsearchpath=
++ pwd
+ lib_search_path=/root/libtool
+ inst_prefix_dir=
+ avoid_version=no
+ dlfiles=
+ dlprefiles=
+ dlself=no
+ export_dynamic=no
+ export_symbols=
+ export_symbols_regex=
+ generated=
+ libobjs=
+ ltlibs=
+ module=no
+ no_install=no
+ objs=
+ non_pic_objects=
+ prefer_static_libs=no
+ preload=no
+ prev=
+ prevarg=
+ release=
+ rpath=
+ xrpath=
+ perm_rpath=
+ temp_rpath=
+ thread_safe=no
+ vinfo=
+ vinfo_number=no
+ test -n ''
+ test 8 -gt 0
+ arg=-o
+ base_compile=gcc -o
+ shift
+ qarg=-o
+ libtool_args=gcc -o
+ test -n ''
+ prevarg=-o
+ prev=output
+ test -n -o
+ compile_command=gcc -o
+ finalize_command=gcc -o
+ test 7 -gt 0
+ arg=test
+ base_compile=gcc -o test
+ shift
+ qarg=test
+ libtool_args=gcc -o test
+ test -n output
+ compile_command=gcc -o @OUTPUT@
+ finalize_command=gcc -o @OUTPUT@
+ eval 'output="$arg"'
++ output=test
+ prev=
+ continue
+ test 6 -gt 0
+ arg=test.o
+ base_compile=gcc -o test test.o
+ shift
+ qarg=test.o
+ libtool_args=gcc -o test test.o
+ test -n ''
+ prevarg=test.o
+ objs= test.o
+ test -n test.o
+ compile_command=gcc -o @OUTPUT@ test.o
+ finalize_command=gcc -o @OUTPUT@ test.o
+ test 5 -gt 0
+ arg=-rpath
+ base_compile=gcc -o test test.o -rpath
+ shift
+ qarg=-rpath
+ libtool_args=gcc -o test test.o -rpath
+ test -n ''
+ prevarg=-rpath
+ prev=rpath
+ continue
+ test 4 -gt 0
+ arg=/usr/lib
+ base_compile=gcc -o test test.o -rpath /usr/lib
+ shift
+ qarg=/usr/lib
+ libtool_args=gcc -o test test.o -rpath /usr/lib
+ test -n rpath
+ test rpath = rpath
+ rpath= /usr/lib
+ prev=
+ continue
+ test 3 -gt 0
+ arg=-L/usr/lib
+ base_compile=gcc -o test test.o -rpath /usr/lib -L/usr/lib
+ shift
+ qarg=-L/usr/lib
+ libtool_args=gcc -o test test.o -rpath /usr/lib -L/usr/lib
+ test -n ''
+ prevarg=-L/usr/lib
++ echo X-L/usr/lib
++ /usr/bin/sed -e '1s/^X//' -e 's/^-L//'
+ dir=/usr/lib
+ deplibs= -L/usr/lib
+ lib_search_path=/root/libtool /usr/lib
+ continue
+ test 2 -gt 0
+ arg=-lpng
+ base_compile=gcc -o test test.o -rpath /usr/lib -L/usr/lib -lpng
+ shift
+ qarg=-lpng
+ libtool_args=gcc -o test test.o -rpath /usr/lib -L/usr/lib -lpng
+ test -n ''
+ prevarg=-lpng
+ test X-lpng = X-lc
+ test X-lpng = X-lm
+ test X-lpng = X-lc_r
+ deplibs= -L/usr/lib -lpng
+ continue
+ test 1 -gt 0
+ arg=-lexpat
+ base_compile=gcc -o test test.o -rpath /usr/lib -L/usr/lib -lpng -lexpat
+ shift
+ qarg=-lexpat
+ libtool_args=gcc -o test test.o -rpath /usr/lib -L/usr/lib -lpng -lexpat
+ test -n ''
+ prevarg=-lexpat
+ test X-lexpat = X-lc
+ test X-lexpat = X-lm
+ test X-lexpat = X-lc_r
+ deplibs= -L/usr/lib -lpn
Re: argv[0] is changed by temporary wrapper script
At Thu, 27 Nov 2003 11:10:14 +0900, [EMAIL PROTECTED] wrote: > So I hope to keep argv[0] for the wrapper, but I have no idea about it > with portability (bash has -a option, but it is not portable). I made a patch for it. The patch makes a temporary progam to use execv(3). Is the patch is acceptable? -- NOKUBI Takatsugu E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] / [EMAIL PROTECTED] libtool-keep-argv0.diff Description: Binary data ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: linking with libexpat.so
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William Trenker wrote: | I have a strange problem that is trivial to reproduce as shown here: | | ~/libtool# libtool --version | ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58) | | ~/libtool# libtool --mode=link gcc -o test test.o -rpath /usr/lib - -L/usr/lib -lpng -lexpat | gcc -o .libs/test test.o -L/usr/lib -lpng /usr/lib/.libs/libexpat.so - -Wl,--rpath -Wl,/usr/lib | gcc: /usr/lib/.libs/libexpat.so: No such file or directory | | Notice how the linker reference for the expat library has been rendered as "/usr/lib//.libs/libexpat.so". Of course there is no such subdirectory as "/usr/lib//.libs/". Yet the reference to libpng.so is simply -lpng as expected. | You have a /usr/lib/libexpat.la which says "installed=no" ... + . /usr/lib/libexpat.la ++ dlname=libexpat.so.0 ++ library_names=libexpat.so.0.1.0 libexpat.so.0 libexpat.so ++ old_library=libexpat.a ++ dependency_libs= ++ current=1 ++ age=1 ++ revision=0 ++ installed=no ++ dlopen= ++ dlpreopen= ++ libdir=/usr/lib + test prog,scan = lib,link I don't know where you got it from, but I'd suggest reinstalling expat (of course you could just edit the .la to say "installed=yes", but there may be other oddities that a complete reinstall would fix and the editing of the .la doesn't). Hope this helps, Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBP9VVI7iDAg3OZTLPAQJ1fQP9HtY09JdBVkjWHa1xbPDk/ps4ywe+a8Nz yyOIbc+ybHggh/xAdlFeHkb/JDnbyk28TzWgY9MgIOPaBprtDkjecDbMAXK30Ult zgEEt1g32iM0tDQiepQhJFuXlBhtrBJFzoNKq9B1kjJGOwWgeh6toEZuwO24cdNc ONC5i90NUcU= =RD7z -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Darwin, convenience libs, and global symbols
I am porting a package to Darwin (compiles fine on Linux) consisting of several convenience libraries, a few test programs, and an application. I'm using Autoconf 2.58, automake 1.7.9, and libtool 1.5 (with the AC_LIBTOOL_TAGS patch). The main application compiles and links correctly, but a test program -- which links the same convenience libraries -- fails with "ld: Undefined symbols" corresponding to the global variables in one of the libraries. The only difference I can think of: the library is constructed by the same Makefile.am as the test program in question (something I do not want to change). Any ideas? I'd be happy to supply any code. Thanks, Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
