Re: ltdl/mdemo test

[Nick Hudson]

On Thursday 13 September 2001 21:30, Gary V. Vaughan wrote:
> On Wed, Sep 12, 2001 at 07:31:41PM +0100, Nick Hudson wrote:
> > On Tuesday 11 September 2001 19:34, Gary V. Vaughan wrote:
[...]
> > >   * ltdl.m4 [AC_LTDL_SYS_DLOPEN_DEPLIBS]: Teach ltdl about the
> > >   behavior of OpenBSD's dlopen().
> >
[...]

> Okay.  Sorry.  I thought that they would have had the same dlopen
> issues.

You right all the BSD derivatives are likely to have the same dlopen issues.

If you remember you introduced this stuff after I pointed out that the dlopen 
behaviour on NetBSD didn't need libltdl to worry about dependencies. I'm 
surprised it took the OpenBSD guys so long to catch up. 

> 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.
>
> Does libtool's configury detect that there is a dlopen function on
> NetBSD, but forget to set HAVE_LIBDL?  I just backported AC_LTDL_DLLIB
> to branch-1-4, so cvs updating may be fruitful...

It looks as though you fixed this with Assar Westerlund's fix...

---
Changes by:  Gary V. Vaughan <[EMAIL PROTECTED]> 01/09/13 15:47:02

Modified files:
 .              : ChangeLog ltdl.m4 

Log message:
 * ltdl.m4 (AC_LTDL_DLLIB): call dlopen with arguments so the test
 does not fail due to a prototype in dlfcn.h

---

>
> Thanks for persevering with me :-)

Its OK. Thanks for listening. :)

Nick

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

Re: make check failures

[Patrick Welche]

On Thu, Sep 13, 2001 at 08:07:48AM +0200, Assar Westerlund wrote:
> Nick Hudson <[EMAIL PROTECTED]> writes:
> > OK. I am now seeing the same thing and the reason is that the configure
> > stuff for libltdl doesn't expect dlopen to exist in libc - it is
> > expecting it in libdl or libsvld. Parts of the configure output are
> > below..
> 
> The simple fix below (relative to cvs libtool) seems to fix the
> problem for me.

Yes, thank you!

Patrick

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

Re: ltdl/mdemo test

[Patrick Welche]

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

[Max Horn]

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=detailsupport&support_id=100049&group_id=25 
(excuse my bad patch there, formating got lost with copy&paste, 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 2>&1

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) ¬hing},
   {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: 
phone: (+49) 6151-494890

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

Re: Darwin / OS X

[Gary V. Vaughan]

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

[Ted Irons]

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

[Gary V. Vaughan]

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

[Max Horn]

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: 
phone: (+49) 6151-494890

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

Re: Darwin & Dynamic modules

[Guido Draheim]

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

[Tor Lillqvist]

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 2>&1 | sed '1q'; exit 0) | egrep '(/dev/null|Invalid 
file or object type)' >/dev/null; then
+  if ("$tmp_nm" -B /dev/null 2>&1 | 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 2>&1 | sed '1q'; exit 0) | egrep /dev/null 
>/dev/null; then
+  elif ("$tmp_nm" -p /dev/null 2>&1 | 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