Re: ltdl/mdemo test
On Thu, Sep 13, 2001 at 09:30:40PM +0100, Gary V. Vaughan wrote: ... HAVE_LIBDL is a misnomer, and should perhaps be renamed to HAVE_DLOPEN, since the additon of a library that contains dlopen is handled separately. Good idea :) Patrick ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Darwin / OS X
HI there,
I am using libtool on Mac OS X (both Darwin 1.3.7 and Darwin 1.4).
Sadly, there are still some problems with conveniance libs, and
others, too.
1) To cite Christoph Pfisterer:
The problem is that convenience libraries are added to both
$convenience and $deplibs. That causes the library to be
listed twice on the final link command line. That's a
problem on platforms with pedantic linkers like Darwin,
which complain about duplicate symbols as a result.
Look at for some more info an a patch, which sadly causes your cdemo
self-tst to fail :/
http://savannah.gnu.org/support/?func=detailsupportsupport_id=100049group_id=25
(excuse my bad patch there, formating got lost with copypaste, but
Christoph added a better one later).
OK, so this causes cdemo to fail... however, since cdemo and a lot of
other make check fail even with libtool 1.4.1 or cvs head on
darwin, we have no way to check fix this. Could somebody please
tell us what fails, then we can try to find a better solution.
Without the patch, several projects that use conveniance libs fail to
build for me; with the patch, they all work fine. So even if this
patch is bad, we need some other patch to support OS X/darwin. (we
meaning: everybody who wants to target darwin, like me or Christoph :)
Sadly, it is not very easy to dig though the libtool code, and
understand it, but we'll try.
2) 30 of 80 make check tests fail on OS X in libtool HEAD-cvs... not good :/
Is there some way to get make check to put out some more info on
what exactly fails? So far what I do is to run the failed tests
manually, though I am not 100% this is the correct thing to do.
Let me give some example:
* tagdemo-make.test
fails because of this:
/usr/bin/ld: Undefined symbols:
_main
___rtti_si
___rtti_user
At no point can I see that it links against libstdc++, so I tried
tagdemo-conf.test (which passes), but I see nothing in there that
attempts to find a run time lib or something. As Darwin basically
uses a somewhat modified version of gcc, I wonder what is the
difference here? Any ideas?
* quote.test
Only sub-test that fails is \\ quoting, i.e.:
= trying: \\ quoting
= failed: mkdir .libs
cc -c -DVAR=\test\ foo.c -fno-common -DPIC -o .libs/foo.o
cc -c -DVAR=\test\ foo.c -o foo.o /dev/null 21
Anything I can do about it? Is this a serious problem for libtool?
* cdemo-make.test
..fails. (cdemo-static.test passed BTW). The output is:
~/Projekte/foreign/libtool/cdemo/.libs
cc -DPACKAGE=\cdemo\ -DVERSION=\0.1\ -DHAVE_MATH_H=1 -I.
-I/Users/maxhorn/Projekte/foreign/libtool/tests/../cdemo -g -O2
-c main.c
/bin/sh ./libtool --mode=link cc -g -O2 -o cdemo main.o libfoo.la
cc -g -O2 -o cdemo main.o -lm
/usr/bin/ld: Undefined symbols:
_foo
_hello
make: *** [cdemo] Error 1
Now of course that fails! The proper link command works fine, though:
cc -g -O2 -o cdemo main.o .libs/libfoo.a
Any hint why it would do this exceedingly strange thing? Also not
that there is no need for -lm on OS X, I thought it would detect that
* demo-make.test
Fails. There seems to be a quoting problem, for the created
helldlS.c look like this:
...
lt_preloaded_symbols[] =
{
{libhello.2.dylib, (lt_ptr) 0},
{hello, (lt_ptr) hello},
{foo, (lt_ptr) foo},
{nothing, (lt_ptr) nothing},
{0, (lt_ptr) 0}
};
There are many more tests failing, but this mail is already very long
and I better stop. Please forgive me and tell me if this mail is
inappropriate. I sincerly would like to overcome these problems by
myself and just submit nice clean patches to you, however, at least
right now I am not able to do so, hence I hope that maybe you as
experts in libtool matters, can help. I fully understand that you
have other probably more important tasks to think of, but I still
hope something can be done on these problem.s
I am still reading through GNU Autoconf, Automake and Libtool, and
excellent book BTW!
Thanks,
Max
P.S.: I think I read in your mailing list archives something about
1.4.2 being released, but the web page still lists 1.4.1 as current?
--
---
Max Horn
Software Developer
email: mailto:[EMAIL PROTECTED]
phone: (+49) 6151-494890
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Darwin / OS X
On Fri, Sep 14, 2001 at 05:34:38PM +0200, Max Horn wrote: I think I read in your mailing list archives something about 1.4.2 being released, but the web page still lists 1.4.1 as current? Indeed. I forgot to update the web page... commiting at the moment. Thanks for prompting me. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
running 'libtool gdb foo' from emacs
One gets used to doing M-x gdb foo in emacs; but if foo is an uninstalled binary one has to do a command line libtool gdb foo Any way of running gdb on an uninstalled binary from emacs? Is there a libtool mode for emacs? Thanks, - Ted ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: running 'libtool gdb foo' from emacs
On Fri, Sep 14, 2001 at 02:40:28PM -0700, Ted Irons wrote: One gets used to doing M-x gdb foo in emacs; but if foo is an uninstalled binary one has to do a command line libtool gdb foo Any way of running gdb on an uninstalled binary from emacs? Is there a libtool mode for emacs? Well, I think that it would be kind of cool for gdb to understand libtool wrapper scripts and simply do the right thing... I imagine that all it would take is a patch :-) Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Darwin Dynamic modules
OK, I think I just found out that this is the reason modules are not built right on darwin: # Commands used to build and install a shared archive. archive_cmds=\$CC \$(test \\x\$module\\ = xyes echo -bundle || echo -dynamiclib) \$allow_undefined_flag -o \$lib \$libobjs \$deplibs\$linker_flags -install_name \$rpath/\$soname \$verstring Changing the two \\ to \ worked nicely for me. Libtool, with this change, produces modules now when asked for them. -vx is really a useful set of options for /bin/sh :) Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Darwin Dynamic modules
Max Horn wrote: OK, I think I just found out that this is the reason modules are not built right on darwin: # Commands used to build and install a shared archive. archive_cmds=\$CC \$(test \\x\$module\\ = xyes echo -bundle || echo -dynamiclib) \$allow_undefined_flag -o \$lib \$libobjs \$deplibs\$linker_flags -install_name \$rpath/\$soname \$verstring Changing the two \\ to \ worked nicely for me. Libtool, with this change, produces modules now when asked for them. it's an old bug - you may want to use this ac-macro to fix it in your project: http://ac-archive.sf.net/guidod/patch_libtool_on_darwin_zsh_overquoting.html cvs libtool has a changelog entry that makes me assume that the zsh overquoting problem has been solved somehow. (/bin/sh on darwin is usually a zsh) but I am not that sure about it. Others have to comment on that. With the above patch tagged into configure.in (after the libtool macros) makes the compilation process to just do what it is supposed to do - to create .so files. If you get to create .dylib's then please tell me how it can be done, okay? TIA... cheers, -- guido (sorry for being this late but web.de had stopped service for a few days) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Suggested pathes to CVC libtool: Mingw improvement, .rc support
Hi,
Here is a patch to libtool with:
-- Small improvement for mingw-hosted tool support (while still
running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
gcc -print-search-dirs still prints its search path with ';' as
separator.
-- Add support for .rc files (Windows resource files), compiled by the
resource compiler (windres in mingw) to .o files.
-- Minor bug fix for $PATH elements with spaces in them when looking
for nm.
-- I think there was some confusion with trailing spaces in
$base_compile in ltmain.in?
ChangeLog entry:
2001-09-15 Tor Lillqvist [EMAIL PROTECTED]
* libtool.m4: Improve handling of mingw gcc. Improve handling of
$PATH with entries containing spaces. Add support for .rc files.
* ltmain.in: Check for .rc files. Add a space to $base_compile in
the case statement, as the case labels checks for trailing
spaces, but there aren't necessarily in $base_compile (?).
Index: configure.ac
===
RCS file: /cvs/libtool/configure.ac,v
retrieving revision 1.4
diff -u -2 -r1.4 configure.ac
--- configure.ac2001/07/09 22:41:58 1.4
+++ configure.ac2001/09/15 02:17:38
@@ -49,4 +49,7 @@
AM_CONDITIONAL(HAVE_GCJ, [test x$GCJ != xno])
+LT_AC_PROG_RC
+AM_CONDITIONAL(HAVE_RC, [test x$RC != xno])
+
# Declare win32 dll support
AC_LIBTOOL_WIN32_DLL
Index: libtool.m4
===
RCS file: /cvs/libtool/libtool.m4,v
retrieving revision 1.231
diff -u -2 -r1.231 libtool.m4
--- libtool.m4 2001/09/11 00:22:48 1.231
+++ libtool.m4 2001/09/15 02:17:41
@@ -1086,5 +1086,16 @@
yes,mingw*)
library_names_spec='${libname}`echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
-sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e
s/^libraries:// -e s/$PATH_SEPARATOR/ /g`
+sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e
+s/^libraries://`
+if echo $sys_lib_search_path_spec | [egrep ';[C-Z]:/' /dev/null]; then
+ # It is most probably a Windows format PATH printed by
+ # mingw gcc, but we are running on Cygwin. Gcc prints its search
+ # path with ; separators, and with drive letters. We can handle the
+ # drive letters (cygwin fileutils understands them), so leave them,
+ # especially as we might pass files found there to a mingw objdump,
+ # which wouldn't understand a cygwinified path. Ahh.
+ sys_lib_search_path_spec=`echo $sys_lib_search_path_spec | sed -e 's/;/ /g'`
+else
+ sys_lib_search_path_spec=`echo $sys_lib_search_path_spec | sed -e
+s/$PATH_SEPARATOR/ /g`
+fi
;;
yes,pw32*)
@@ -1408,5 +1419,5 @@
[include additional configurations @:@CXX,GCJ@:@])],
[tagnames=$withval],
-[tagnames=CXX,GCJ])
+[tagnames=CXX,GCJ,RC])
if test -f $ltmain test -n $tagnames; then
@@ -1456,4 +1467,8 @@
;;
+ RC)
+AC_LIBTOOL_LANG_RC_CONFIG
+;;
+
*)
AC_MSG_ERROR([Unsupported tag name: $tagname])
@@ -2018,14 +2033,14 @@
IFS=$lt_save_ifs
test -z $ac_dir ac_dir=.
-tmp_nm=$ac_dir/${ac_tool_prefix}nm
-if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
+tmp_nm=$ac_dir/${ac_tool_prefix}nm
+if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
# Check to see if the nm accepts a BSD-compat flag.
# Adding the `sed 1q' prevents false positives on HP-UX, which says:
# nm: unknown option B ignored
# Tru64's nm complains that /dev/null is an invalid object file
- if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | egrep '(/dev/null|Invalid
file or object type)' /dev/null; then
+ if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | egrep '(/dev/null|Invalid
+file or object type)' /dev/null; then
lt_cv_path_NM=$tmp_nm -B
break
- elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | egrep /dev/null
/dev/null; then
+ elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | egrep /dev/null
+/dev/null; then
lt_cv_path_NM=$tmp_nm -p
break
@@ -2165,4 +2180,19 @@
+# AC_LIBTOOL_RC
+# --
+# enable support for Windows resource files
+AC_DEFUN([AC_LIBTOOL_RC],
+[AC_REQUIRE([_LT_AC_LANG_RC])
+])# AC_LIBTOOL_RC
+
+
+# _LT_AC_LANG_RC
+# ---
+AC_DEFUN([_LT_AC_LANG_RC],
+[AC_REQUIRE([AC_PROG_RC])
+])# _LT_AC_LANG_GCJ
+
+
# AC_LIBTOOL_LANG_C_CONFIG
#
@@ -3158,4 +3188,48 @@
+# AC_LIBTOOL_LANG_RC_CONFIG
+# --
+# Ensure that the configuration vars for the Windows resource compiler are
+# suitably defined. Those variables are subsequently used by
+# AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
+AC_DEFUN([AC_LIBTOOL_LANG_RC_CONFIG], [_LT_AC_LANG_RC_CONFIG(RC)])
+AC_DEFUN([_LT_AC_LANG_RC_CONFIG],
+[AC_LANG_SAVE
+
+# Source file extension for RC test sources.
