Re: msys/mingw warnings about string length and putenv absence with gcc -Wall -ansi

Charles Wilson wrote:

> Okay, this is looking more involved. I'll have to do the whole
> regression thing...sigh.

Patch here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00004.html

--
Chuck

link-order.at test set wrong -L?

Hi,

When looking at the results of the link-order.at test, I notice that
24/new/lib/liba.so has this rapth set:
  RPATH       /home/kurt/libtool/git/tests/testsuite.dir/24/new/lib:/home/kurt/libtool/git/tests/testsuite.dir/24/old/lib

It probably shouldn't have this old dir in it, since it contains the other
libb.so that has other symbols.

I think the problem is that the testsuite uses -L on the old dir, while
the second time it should probably use -L on the new dir.

Kurt

Cannot link correct libltdl.so. Is it a bug?

I got errors when I do the cross compile for powerpc. Below are the error messages. It looks for
/usr/lib/libltdl.so instead of /tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so at link time. I set the
path -L/tools/eldk/4.2/ppc_4xx/usr/lib. But, it is useless. Below are details.

Before running ./configure, I set the environment variables below

setenv LDFLAGS  -L/tools/eldk/4.2/ppc_4xx/usr/lib
setenv CPPFLAGS -I/tools/eldk/4.2/ppc_4xx/usr/include

setenv CROSS_COMPILE ppc_4xx-
setenv ARCH powerpc
setenv BUILD_CC gcc
setenv CC powerpc-linux-gcc
setenv AR powerpc-linux-ar
setenv RANLIB powerpc-linux-ranlib
set path=(/tools/eldk/4.2/bin /tools/eldk/4.2/usr/bin $path)

./configure --prefix=/tmp/install_libs --host=powerpc-linux --build=i686-pc-linux-gnu -target=powerpc-linux

./configure runs successfully with the following warnings

configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf <at> gnu.org.
Package libexif was not found in the pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found
config.status: WARNING:  po/Makefile.in.in seems to ignore the --datarootdir setting

Problem with LT_PATH_NM

The other day I downloaded and tried to build the latest
version of stable glib (2.18.4) where they apparently had
switched from libtool 1.5.x to libtool 2.2.x. The build
failed with the following error:

libtool: link: link -dump -symbols  .libs/garray.o .libs/gasyncqueue.o .libs/gatomic.o
.libs/gbacktrace.o .libs/gbase64.o .libs/gbookmarkfile.o .libs/gcache.o .libs/gchecksum.o
.libs/gcompletion.o .libs/gconvert.o .libs/gdataset.o .libs/gdate.o .libs/gdir.o
.libs/gerror.o .libs/gfileutils.o .libs/ghash.o .libs/ghook.o .libs/giochannel.o
.libs/gkeyfile.o .libs/glist.o .libs/gmain.o .libs/gmappedfile.o .libs/gmarkup.o .libs/gmem.o
.libs/gmessages.o .libs/gnode.o .libs/goption.o .libs/gpattern.o .libs/gprimes.o
.libs/gqsort.o .libs/gqueue.o .libs/grel.o .libs/grand.o .libs/gregex.o .libs/gscanner.o
.libs/gsequence.o .libs/gshell.o .libs/gslice.o .libs/gslist.o .libs/gstdio.o
.libs/gstrfuncs.o .libs/gstring.o .libs/gtestutils.o .libs/gthread.o .libs/gthreadpool.o
.libs/gtimer.o .libs/gtree.o .libs/guniprop.o .libs/gutf8.o .libs/gunibreak.o
.libs/gunicollate.o .libs/gunidecomp.o .libs/gurifuncs.o .libs/gutils.o .libs/gprintf.o
.libs/giounix.o .libs/gspawn.o   libcharset/.libs/libcharset.a gnulib/.libs/libgnulib.a
pcre/.libs/libpcre.a |  | /bin/sed 's/.* //' | sort | uniq > .libs/libglib-2.0.exp
../libtool: eval: line 964: syntax error near unexpected token `|'

It is obvious that the error is the doubled "| |", which is
due to $global_symbol_pipe being empty. This in turn is due to
the fact that libtool has chosen "link -dump -symbols" as $NM...
This seemed extremely weird and after some searching I found 
the following difference in glib's aclocal.m4 between the 
1.5.x and 2.2.x version:

-# AC_PROG_NM
+
+# LT_PATH_NM

Re: Problem with LT_PATH_NM

Hi Peter,

Thanks for the bug report. As the one who introduced the
dumpbin support I feel obliged to respond...

Den 2009-01-14 14:29 skrev Peter Kjellerstedt:
> I would say that there are two bugs here: 
> * the first is that the code looking for nm in 
>   "$PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin" (not seen 
>   in the patch above) is not doing its job. My $PATH contains 
>   "...:/usr/bin:.." where nm is installed, but the for loop 
>   does not split the colon separated $PATH correctly and thus 
>   does not find /usr/bin/nm.

My bash splits my $PATH correctly using that construct. Something
else is probably going on, maybe that construct isn't portable?
I should also add that the code added to support dumpbin did not
touch the nm locator code, and the dumpbin code is only entered if
nm is not found.

What shell are you using? (I think it's reported in libtool --help)

What does the below script output for you? (with the ???sh replaced
with whatever you are using for $CONFIG_SHELL)

----------8<------------
#!???sh
save_ifs="$IFS"
IFS=:
for i in $PATH /usr/bin /bin; do

Re: Problem with LT_PATH_NM

Den 2009-01-14 14:29, skrev Peter Kjellerstedt:
> The other day I downloaded and tried to build the latest
> version of stable glib (2.18.4) where they apparently had
> switched from libtool 1.5.x to libtool 2.2.x. The build
> failed with the following error:

Are you perhaps cross-compiling (host != build), in that case
you are probably hitting this:

http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00019.html

.oO(Should have remembered that post earlier...)

Cheers,
Peter

Re: Problem with LT_PATH_NM

Den 2009-01-14 20:24 skrev Peter Rosin:
> Den 2009-01-14 14:29 skrev Peter Kjellerstedt:
>> * the second is that my /usr/bin/link should not be used as NM
>>   since it obviously does not support the options required (as
>>   it is the wrong program).
> 
> Can't argue about that, but you should never end up looking for
> "link" if you have nm on your path, so that's a red herring in
> my opinion. If the nm locator code is fixed, this is a non-issue.
> Further, if nm is not on $PATH, it doesn't make any sense to
> set NM=nm.

Here's a patch that makes the configure check a bit more picky
about what it recognizes as "dumpbin". As it happens, the MS
dumpbin outputs:

Microsoft (R) COFF/PE Dumper Version x.yy.zzzzz.www

as its first line of output, so I'm triggering on *COFF*

With this patch, the old fallback (NM=nm) should kick in and
save you.

Does this help?

(But it just papers over the real bug IMHO)

Cheers,
Peter

Re: Problem with LT_PATH_NM

Den 2009-01-14 22:38 skrev Peter Rosin:
> Here's a patch that makes the configure check a bit more picky

"/&#%/#, wrong version of the patch.

Here's what I intended.

Cheers, and sorry for spamming,
Peter

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b7b566d..4968bf8 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
 <at>  <at>  -3156,7 +3156,19  <at>  <at>  if test "$lt_cv_path_NM" != "no"; then
   NM="$lt_cv_path_NM"
 else
   # Didn't find any BSD compatible name lister, look for dumpbin.
-  AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"], :)
+  if test -n "$DUMPBIN"; then :
+    # Let the user override the test.
+  else
+    AC_CHECK_TOOLS(DUMPBIN, [dumpbin "link -dump"], :)
+    case `$DUMPBIN -symbols /dev/null 2>&1 | sed '1q'` in
+    *COFF*)
+      DUMPBIN="$DUMPBIN -symbols"
+      ;;
+    *)
+      DUMPBIN=:

RE: Problem with LT_PATH_NM

> -----Original Message-----
> From: Peter Rosin [mailto:peda <at> lysator.liu.se]
> Sent: den 14 januari 2009 21:27
> To: Peter Kjellerstedt
> Cc: bug-libtool <at> gnu.org
> Subject: Re: Problem with LT_PATH_NM
> 
> Den 2009-01-14 14:29, skrev Peter Kjellerstedt:
> > The other day I downloaded and tried to build the latest
> > version of stable glib (2.18.4) where they apparently had
> > switched from libtool 1.5.x to libtool 2.2.x. The build
> > failed with the following error:
> 
> Are you perhaps cross-compiling (host != build), in that case
> you are probably hitting this:
> 
> http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00019.html
> 
> .oO(Should have remembered that post earlier...)
> 
> Cheers,
> Peter

Ah yes, forgot to mention that we are in fact cross-compiling.
And from my further testing, it seems the $PATH handling works 
correctly, it is just that it never looks for "nm" since we are 
cross-compiling. But I do not understand why that isn't done, 
since NM is set to nm unconditionally at the end anyway if 
nothing has been found. So IMHO it might just as well search 
for it properly. But I guess there may be more to it...

file magic regex for hppa*64*

The file magic regex for detecting PA-RISC shared objects only works for native
HP-UX file command. This prevents from using a BSD file command and from
building a cross compiler from Linux to HP-UX, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

Please, CC me because I'm off list.

--
Mit freundlichen Grüßen / Best Regards

Dipl.-Ing. Rainer Emrich
Dept. Manager IT
TECOSIM Venture GmbH
Ferdinand-Stuttmann-Straße 15
D-65428 Rüsselsheim
Phone  +49 (0) 6142 8272-330
Fax    +49 (0) 6142 8272-249
Mobile +49 (0) 163 5694920
www.tecosim.com
best partner for simulation
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

TECOSIM Venture GmbH, Rüsselsheim
Firmensitz: Ferdinand-Stuttmann-Straße 15, 65428 Rüsselsheim
Registergericht: Amtsgericht Darmstadt, HRB 83704
Geschäftsführer: Udo Jankowski, Jürgen Veith