Jens Petersen | 1 May 05:44 2003
Picon

AC_LIBTOOL_PROG_CC_C_O assumes cwd needn't be writable

I received the following bug report:

	http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89887

which describes how icc apparently hits the following problem described
in the source of the above macro:

   # According to Tom Tromey, Ian Lance Taylor reported there are C compilers
   # that will create temporary files in the current directory regardless of
   # the output directory.  Thus, making CWD read-only will cause this test
   # to fail, enabling locking or at least warning the user not to do parallel
   # builds.
   chmod -w .

Comments?

Jens
Richard A Ryan | 1 May 18:41 2003
Picon

libtool 1.5 on Solaris 9 with two gcc

Hi,

I'm running libtool 1.5 on Solaris 9.  I'm compiling
with and linking through gcc 3.2.1 in the location
/opt/GCC/bin.  There is also gcc 3.2 in /usr/local/bin.
The problem I'm having with libtool 1.5 that I didn't
have with libtool 1.4.3 is that now libtool seems to be
trying to link with that same libraries in both /usr/local
and /opt/GCC

Here's from the last few lines of output:

/bin/bash ../libtool --mode=link g++  -g -O2 -fpermissive   -o LdmNexrad2NetCDF  LdmNexrad2NetCDF.o
libOdsNexradLib.la -lz -lnsl -lm -llzo -lbz2 
g++ -g -O2 -fpermissive -o LdmNexrad2NetCDF LdmNexrad2NetCDF.o  ./.libs/libOdsNexradLib.a
-L/usr2/SOURCES/S9/gcc-3.2/objdir/sparc-sun-solaris2.9/libstdc++-v3/src
-L/usr2/SOURCES/S9/gcc-3.2/objdir/sparc-sun-solaris2.9/libstdc++-v3/src/.libs
-L/usr2/SOURCES/S9/gcc-3.2/objdir/gcc -L/usr/local/udunits/lib -L/usr/local/netcdf/lib
-lnetcdf_c++ -L/usr/local/ldm/lib -ludunits -lnetcdf -lldm /usr/local/lib/libstdc++.so
-L/usr/ccs/bin -L/usr/ccs/lib -lgcc_s -lz -lnsl -lm /usr/local/lib/liblzo.a -lbz2 -Wl,-R
-Wl,/usr/local/lib -Wl,-R -Wl,/usr/local/lib
ld: fatal: recording name conflict: file `/usr/local/lib/libstdc++.so' and file
`/opt/GCC/lib/gcc-lib/sparc-sun-solaris2.9/3.2.1/../../../libstdc++.so' provide identical
dependency names: libstdc++.so.5  (possible multiple inclusion of the same file)
ld: fatal: File processing errors. No output written to LdmNexrad2NetCDF
collect2: ld returned 1 exit status
make[3]: *** [LdmNexrad2NetCDF] Error 1
make[3]: Leaving directory `/scratch/ryan/nexrad_scratch/ods/base/Nexrad'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/scratch/ryan/nexrad_scratch/ods/base/Nexrad'
(Continue reading)

Lee, Jung Hae | 7 May 21:03 2003

error running libtool 1.5 on HP-UX 11.0

For your info, I had attached the output that "make check" generated.   What
can I do resolve this? <<makecheck.list>> 
Jung Hae Lee

Attachment (makecheck.list): application/octet-stream, 2541 bytes
_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-libtool
Robert Boehne | 8 May 05:59 2003
Picon

Re: libtool-1.5 regression test failure (Solaris 8 + gcc-3.22)

Chuck Swiger wrote:
> 
> As requested below by Robert:
> 
<SNIP>
> /bin/bash ./libtool --mode=link gcc  -pipe -O2   -o libhello.la -rpath
> /usr/local/lib -no-undefined -version-info 3:12:1 hello.lo foo.lo -lm
> gcc -shared -Wl,-h -Wl,libhello.so.2 -o .libs/libhello.so.2.1.12
> .libs/hello.o.libs/foo.o  -lm -lc
> Text relocation remains                         referenced
>      against symbol                  offset      in file
> <unknown>                           0x4         .libs/hello.o
> <unknown>                           0x8         .libs/hello.o
> <unknown>                           0x18        .libs/foo.o
> <unknown>                           0x1c        .libs/foo.o
> cos                                 0x8         .libs/foo.o
> puts                                0xc         .libs/hello.o
> printf                              0x24        .libs/foo.o
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
> make[3]: *** [libhello.la] Error 1

Chuck,

This really looks like the compiler, can you build a shared lib without
Libtool?

Robert
Richi Plana | 10 May 21:31 2003
Picon

Test FAIL for libtool-1.5 on RH9

Hi,

Tried to compile libtool-1.5 on RH9 using automake-1.6 and 
autoconf-2.57. The ff. libtool tests failed after testing:

FAIL: demo-make.test
FAIL: sh.test
FAIL: pdemo-make.test
--

-- 

*Richard Plana, B.Sc., CCNA*
Linux Junkie
Adrian Bunk | 11 May 13:35 2003
Picon
Picon

libtool 1.5: "make check" fails on NetBSD/sparc-1.5

<--  snip  -->

$ VERBOSE=x TESTS='tagdemo-exec.test' make -e check
...
gmake[2]: Entering directory `/aux/adrian/build/libtool-1.5/tests'
=== Running tagdemo-exec.test
Executing uninstalled programs in ../tagdemo
/aux/adrian/build/libtool-1.5/tagdemo/./.libs/libbaz.so.0: Undefined 
symbol "" (reloc type = 12, symnum = 18)
./tagdemo-exec.test: cannot execute ../tagdemo/tagdemo
FAIL: tagdemo-exec.test
====================================
1 of 1 tests failed
Please report to bug-libtool <at> gnu.org
====================================
gmake[2]: *** [check-TESTS] Error 1
...

<--  snip  -->

Environment:
sparc-unknown-netbsdelf1.5
gcc 2.95.3 (slightly patched for NetBSD)
GNU binutils 2.13.2.1

Any other information that might be useful for you?

cu
Adrian

(Continue reading)

Wayne Stewart | 13 May 18:30 2003

lt_dlerror() returns NULL?

Hi,

It seems to me that either the documentation is wrong, or the function
is.  I don't see any way that 'lt_dlerror()' can return NULL.

  - Function: const char * lt_dlerror (void)
      Return a human readable string describing the most recent error
      that occurred from any of libltdl's functions.  Return `NULL' if
      no errors have occurred since initialization or since it was last
      called.

    const char *
    lt_dlerror ()
    {
      const char *error;

      LT_DLMUTEX_GETERROR (error);
      LT_DLMUTEX_SETERROR (0);

      return error ? error : LT_DLSTRERROR (UNKNOWN);
    }

----
    Wayne
Laurent | 14 May 06:49 2003
Picon
Picon

AIX, -Wl,-brtl and DESTDIR

Hi,

I'm trying to build glib-2.2.1 on AIX 5L. To build the modules, I'm using the -Wl,-brtl option (as LDFLAGS),
but when I'm trying to install glib in a different location (with the DESTDIR option), libtool fails to
relink the librairies...

Here the last messages from make

/bin/sh ../libtool  --mode=install /opt/bin/install -c libgobject-2.0.la /tmp/install/opt/lib/libgobject-2.0.la
libtool: install: warning: relinking `libgobject-2.0.la'
(cd /home/goujon/glib-2.2.1/gobject; /bin/sh ../libtool --mode=relink gcc -g -O2 -Wall -L/opt/lib
-Wl,-brtl -o libgobject-2.0.la -rpath /opt/lib -version-info 200:1:200 -export-dynamic gboxed.lo
gclosure.lo genums.lo gobject.lo gparam.lo gparamspecs.lo gsignal.lo gsourceclosure.lo gtype.lo
gtypemodule.lo gtypeplugin.lo gvalue.lo gvaluearray.lo gvaluetransform.lo gvaluetypes.lo
../glib/libglib-2.0.la -lintl -inst-prefix-dir /tmp/install)
generating symbol list for `libgobject-2.0.la'
/bin/nm -B  gboxed.o gclosure.o genums.o gobject.o gparam.o gparamspecs.o gsignal.o gsourceclosure.o
gtype.o gtypemodule.o gtypeplugin.o gvalue.o gvaluearray.o
gvaluetransform.o gvaluetypes.o   | sed -n -e 's/^.*[   ]\([BCDT][BCDT]*\)[
][      ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort | uniq > .libs/libgobject-2.0.exp
gcc -o .libs/libgobject-2.0.so.0.200.1  gboxed.o gclosure.o genums.o gobject.o gparam.o
gparamspecs.o gsignal.o gsourceclosure.o gtype.o gtypemodule.o gtypeplugin.o gvalue.o
gvaluearray.o gvaluetransform.o gvaluetypes.o  -Wl,-blibpath:/opt/lib:/usr/lib:/lib  -L/opt/lib
/opt/lib/libglib-2.0.so /opt/lib/libintl.a  -lc  -Wl,-brtl `if test "x-berok" != "x"; then echo
"-Wl,-berok"; else :; fi` -Wl,-bnoentry -Wl,-bexport:.libs/libgobject-2.0.exp -shared
gcc: /opt/lib/libglib-2.0.so: No such file or directory
libtool: install: error: relink `libgobject-2.0.la' with the above command before installing it

As you can see, libtool has correctly detected the DESTDIR (/tmp/install) but tries to build
libgobject-2.0.so.0.200.1 from /opt/lib/libglib-2.0.so which doesn't exist because it hasn't been installed...
(Continue reading)

Ulrik Petersen | 15 May 14:08 2003
Picon

Libtool and staged installs (-L$install-libdir before -L$staged-install-libdir)

Hello,

I'm using a fairly recent CVS snapshot of libtool (April 25, 2003),
along with a CVS snapshot of autoconf from the same day, and Automake
1.7.4.

Automake allows "staged installs".  A description of how to do "staged
installs" could be as follows (taking my Emdros software package as an
example):

-- example description begins --
The following assumes that you want to install in /opt/Emdros and build
the package in /var/tmp/Emdros before installing.

1. ./configure --prefix=/opt/EmdrosPQ
2. make
3. mkdir /tmp/EmdrosPQ
4. make DESTDIR=/tmp/EmdrosPQ install
5. build package in /tmp/EmdrosPQ for installation in /opt/EmdrosPQ
-- example description ends --

When running

$ make DESTDIR=/tmp/EmdrosPQ install

libtool relinks the shared libraries.  Below I have reproduced four
lines of the output from this command, with most spaces converted to
newlines + indentation.  The lines are numbered.

1. /bin/bash ../libtool --mode=install .././install-sh -c  libmql.la
(Continue reading)

Mitja Pirih | 17 May 10:53 2003

3 errors found running make check (libtool-1.5)

OS: OpenBSD 3.3 (current)
autoconf-2.57 
automake-1.7
m4-1.4

====================================
3 of 104 tests failed
(1 tests were not run)
Please report to bug-libtool <at> gnu.org
====================================
*** Error code 1

Stop in /usr/src/libtool-1.5/tests (line 324 of Makefile).
*** Error code 1

Stop in /usr/src/libtool-1.5/tests (line 358 of Makefile).
*** Error code 1

Stop in /usr/src/libtool-1.5 (line 339 of Makefile).

Regards,
Mitja 
Attachment (tests.tar.gz): application/x-gzip, 24 KiB
_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-libtool
(Continue reading)


Gmane