Re: Passing LD_RUN_PATH through to the linker
0d (FINI) 0x4daf0 > 0x000e (SONAME) Library soname: > [/usr/local/lib/libssh2.so.1] > 0x001d (RUNPATH)Library runpath: [/usr/local/lib] > 0x0004 (HASH) 0xc0 > 0x0005 (STRTAB) 0x5498 > 0x0006 (SYMTAB) 0x1408 > 0x000a (STRSZ) 18886 (bytes) > 0x000b (SYMENT) 16 (bytes) > 0x0016 (TEXTREL)0x0 > 0x0003 (PLTGOT) 0x4ec2c > 0x0002 (PLTRELSZ) 40 (bytes) > 0x0014 (PLTREL) REL > 0x0017 (JMPREL) 0xfb18 > 0x0011 (REL)0x9e60 > 0x0012 (RELSZ) 23736 (bytes) > 0x0013 (RELENT) 8 (bytes) > 0x (NULL) 0x0 > > I'm assuming there must be something else different in the way we build. Which development system are you using? OpenServer 5.0..7 had 3 different ones available. OpenServer 5 Definitive 2018 has 4. The latest being a GCC 4.2.4 and friends. > > Regards, > Kevin R. Bulgrien > -- Tim RiceMultitalents t...@multitalents.net
Re: Passing LD_RUN_PATH through to the linker
Kevin,
On Wed, 14 Dec 2022, Kevin R. Bulgrien wrote:
> During attempts to build top-of-tree libssh2 on a dinosaur (SCO OpenServer
> 5.0.7),
> an issue with loading indirect dependencies of libssh2.so is occurring. They
> can
> be worked around by setting LD_LIBRARY_PATH at run-time, however it seems much
> simpler to depend on DT_RPATH so the run-time environment does not require
> management.
>
> The linker behaves as defined at the link following (ironically, more
> completely
> documented on this list than in the official documentation):
>
> https://lists.gnu.org/archive/html/bug-libtool/2002-08/msg00026.html
>
[snip]
>
> Can anyone offer a pointer on where to look in autotools/libtool structure
> to get DT_RPATH set in the linked binaries or comment on whether this is
> even an option with libtool? I'm finding difficulty differentiating
> between -R and -rpath for libtool versus similar switches for ld.
On OpenServer, I usually just build with the SONAME being a full path name.
I am attaching a patch to the libtool 2.4.6 generated during
a libssh2-1.8.0 build.
Once all testing is complete, I do
..
rm src/libssh2.la
SCOABSPATH=1 ; export SCOABSPATH
gmake 2>&1 | tee x.log
..
then package.
Note: the last hunk is to address a regression introduced in 2.4.6
with the freebsd reorg.
--
Tim RiceMultitalents
t...@multitalents.net
--- libtool.old 2022-12-15 13:35:00.869441000 +
+++ libtool 2022-12-15 13:38:25.699441000 +
@@ -359,8 +359,8 @@
old_archive_from_expsyms_cmds=""
# Commands used to build a shared archive.
-archive_cmds="\$CC -G \$wl-h,\$soname -o \$lib \$libobjs \$deplibs
\$compiler_flags"
-archive_expsym_cmds="\$CC -G \$wl-Bexport:\$export_symbols \$wl-h,\$soname -o
\$lib \$libobjs \$deplibs \$compiler_flags"
+archive_cmds="\$CC -G \${wl}-h,\\\${SCOABSPATH:+\${install_libdir}/}\$soname
-o \$lib \$libobjs \$deplibs \$compiler_flags"
+archive_expsym_cmds="\$CC -G \${wl}-Bexport:\$export_symbols
\${wl}-h,\\\${SCOABSPATH:+\${install_libdir}/}\$soname -o \$lib \$libobjs
\$deplibs \$compiler_flags"
# Commands used to build a loadable module if different from building
# a shared archive.
@@ -378,7 +378,7 @@
# Flag to hardcode $libdir into a binary during linking.
# This must work even if $libdir does not exist
-hardcode_libdir_flag_spec="\$wl-R,\$libdir"
+hardcode_libdir_flag_spec="\`test -z \"\$SCOABSPATH\" && echo -R\$libdir | sed
's|-R/opt/xinuos/lib | |'\`"
# Whether we need a single "-rpath" flag with a separated argument.
hardcode_libdir_separator=":"
@@ -7552,6 +7552,7 @@
;;
-module)
+ unset SCOABSPATH
module=yes
continue
;;
@@ -9314,7 +9315,7 @@
age=$number_minor
revision=$number_revision
;;
- freebsd-aout|qnx|sunos)
+ freebsd-aout|qnx|sco|sunos)
current=$number_major
revision=$number_minor
age=0
Re: Are *.la files supposed to be executable?
Hi Jeff, On Sat, 9 Jan 2021, Jeffrey Walton wrote: > Hi Everyone, > > I'm auditing $prefix for ownership and permissions. I noticed *.la > files are executable: > > $ ls -Al /usr/local/lib/libgettextlib.la > -rwxr-xr-x 1 root root 1078 Jan 8 15:58 /usr/local/lib/libgettextlib.la [snip] > Are the *.la files supposed to be executable? Since libtool sources the .la files, they do not need to be executable. You will see a mix of executable and non-executable in various distos. My packaging scripts do a chmod 644 on them. > Jeff > -- Tim RiceMultitalents t...@multitalents.net
Re: libtool-2.4.2.418 released [alpha]
Hi Gary and Tim, On Wed, 6 Nov 2013, Gary V. Vaughan wrote: | Hi Tim, | | > On 6 Nov 2013, at 11:20, Tim Mooney wrote: | >> The Libtool Team is pleased to announce the release of libtool 2.4.2.418. | > | >> This is a preliminary alpha release to begin platform testing in | >> preparation for the next stable release. | > | > I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with | > the Oracle Studio 12.3 toolchain. There was one unexpected failure | > in the new test suite: | > | > 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) | | Yes, I'm seeing this failure on quite a few of my test architectures too, but | haven't been able to get to the bottom of it. If you have any insight, I'd be | very happy to hear about it. Gary, in bug#15734 you sugested it was a problem with grep. On my UnixWare box, I tested with a GNU grep first in the path and #21 did not fail. Now, which part is tripping up the system grep and what to do about it, I do not know. ;-) -- Tim RiceMultitalents(707) 456-1146 t...@multitalents.net ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf, On Sat, 28 Feb 2009, Ralf Wildenhues wrote: [snip] > Is this an optimization only, or a necessary thing? IOW, if I omit > libfoo-1.0 in this "CC -Tprelink_objects" line, would that only > pessimize link time, or could it affect the link result? I'll let John answer this > Anyway, I think the patch below should implement this (and add John to > THANKS). Can you try it? Thanks. The test still fails although the patch could be correct. It looks like this never makes it into the generated libtool. > + _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$CC > -r -o $output$reload_objs' . t...@server01-unixware 132% grep Tprelink libtool old_archive_cmds="\$CC -Tprelink_objects \$oldobjs~ . In fact there is no reload_cmds= in the TAG CONFIG: CXX section . t...@server01-unixware 133% grep -n "^reload_cmds=" libtool 123:reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs" t...@server01-unixware 134% grep -n "CONFIG: CXX" libtool 9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX 9245:# ### END LIBTOOL TAG CONFIG: CXX . -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf, On Wed, 25 Feb 2009, Ralf Wildenhues wrote: : Hi Tim, : : * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET: : > On Sat, 21 Feb 2009, Ralf Wildenhues wrote: : > > * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET: : > > > : > > > I'm trying to understand the cmdline_wrap.at test. : > > > I've added this patch to fix the 2 template tests that were failing : > > > on UnixWare 7.1.4 : > > : > > Can you post the verbose output of the test both without and with the : > > patch? Thanks. : > > gmake check-local TESTSUITEFLAGS='-k "simple template test" -v -d -x' : > : > Sure, attched as x.tst-without-patch & x.tst-with-patch : > I've also attached the curent patch I'm using as uw-template.patch : > It's just a s/CXX/CC/ of the old one. : : How come there is no ranlib step in old_archive_cmds? Simple, there is no ranlib on UnixWare. : Otherwise, if it causes no other testsuite regressions, it looks good to : me. No other regressions. : > > How long is the actual command line length limit on your system? : > > If it is >1MB or unlimited, then this is unlikely to ever be a problem : > > in practice, and you can ignore the failure. But some systems have : > > pretty low limits. : > : > On my system it is 131072 but it is a kernel tunable and the default : > out of the box is 32k. : : That's too low for some packages. Indeed, but it can be tuned as high as 1048576. : > > The output of the failing/passing of the test above may help analyze the : > > failure of the cmdline_wrap test. : > : > John Wolfe was looking at this too (using 2.2.6) and here is what : > he had to say : > -- : > I know why test 73 (small command line) test fails on #62 (C++ : > templates). : > : >- one of the link lines (second) linking against a .la, gets : > broken up and .o's are collected in a relocatable object using. : > : > /bin/ld -r : > : > Ergo the problem, the prelink phase is skipped. It is not a : > problem with the archive being built, since $AR can accumulate : > object files, 1 file at a time. : > So the CC -Tprelink_objects is accomplished as expected - just : > before the $AR. : > The prelinker command echo can be seen in the log. : > : > For shared objects, what is needed is to get a CC -Tprelink_objects : > done on the libobjs before they are added to the relocatable object. : : Can you show how it would need to work? If libtool reloads : a.o b.o c.o -> libfoo-1.o : d.o e.o f.o libfoo-1.o -> libfoo-2.o : and links : g.o libfoo-2.o -> libfoo.la : : then which objects does CC -Tprelink_objects need to be run on? Maybe we can get John to comment on this one. He knows the C++ compile much better than I do. : > The /bin/ld cannot be replaced with $CC since the C++ compiler : > driver will link in startup modules also. Soon get a multiple : > defined symbol. : : Yes. : : Thanks, : Ralf -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
SCOABSPATH in 2.x
I noticed that the SCOABSPATH bits are in aclocal.m4 on 2.2.6 and was wondering how they got there since the corresponding changes to libltdl/m4/libtool.m4 were intentionally not forward ported from the 1.5 branch. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf,
On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
> >
> > I'm trying to understand the cmdline_wrap.at test.
> > I've added this patch to fix the 2 template tests that were failing
> > on UnixWare 7.1.4
>
> Can you post the verbose output of the test both without and with the
> patch? Thanks.
> gmake check-local TESTSUITEFLAGS='-k "simple template test" -v -d -x'
Sure, attched as x.tst-without-patch & x.tst-with-patch
I've also attached the curent patch I'm using as uw-template.patch
It's just a s/CXX/CC/ of the old one.
> > so now the only failure is the "low max_cmd_len" test.
>
> OK, cool.
>
> > I guess I don't really know what cmdline_wrap.at is trying to acomplish.
> > And I'm puzzled why the "simple template test" fails inside cmdline_wrap
> > but not outside of it.
>
> Well, it tries to simulate a very long command line, so long that its
> expansion by libtool will exceed the kernel command line length limit.
> It does this by setting the limit very low, which libtool internally
> compares against. So then the wrapping code branches are exercised,
> which create intermediate libraries or objects.
>
> How long is the actual command line length limit on your system?
> If it is >1MB or unlimited, then this is unlikely to ever be a problem
> in practice, and you can ignore the failure. But some systems have
> pretty low limits.
On my system it is 131072 but it is a kernel tunable and the default
out of the box is 32k.
> The test case tries to re-run all kinds of other tests in our testsuite
> (exactly those that only exercise the $LIBTOOL script), for best
> possible code coverage.
>
> The output of the failing/passing of the test above may help analyze the
> failure of the cmdline_wrap test.
John Wolfe was looking at this too (using 2.2.6) and here is what
he had to say
--
I know why test 73 (small command line) test fails on #62 (C++
templates).
- one of the link lines (second) linking against a .la, gets
broken up and .o's are collected in a relocatable object using.
/bin/ld -r
Ergo the problem, the prelink phase is skipped. It is not a
problem with the archive being built, since $AR can accumulate
object files, 1 file at a time.
So the CC -Tprelink_objects is accomplished as expected - just
before the $AR.
The prelinker command echo can be seen in the log.
For shared objects, what is needed is to get a CC -Tprelink_objects
done on the libobjs before they are added to the relocatable object.
The /bin/ld cannot be replaced with $CC since the C++ compiler
driver will link in startup modules also. Soon get a multiple
defined symbol.
--
Thanks.
>
> Thanks!
> Ralf
>
--
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net--- libltdl/m4/libtool.m4.old 2009-02-18 18:54:38.0 -0800
+++ libltdl/m4/libtool.m4 2009-02-22 20:54:26.786787091 -0800
@@ -6219,6 +6219,8 @@
CC*)
_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs
$compiler_flags'
+ _LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
+ $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
abs_srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd /home2/src/gnu/libtool-2.x &&
pwd`; cd tests; \
CONFIG_SHELL="/bin/ksh" /bin/ksh $abs_srcdir/tests/testsuite \
MAKE="gmake" CC="cc" CFLAGS="-g" CPP="cc -E" CPPFLAGS="" LD="/usr/bin/ld"
LDFLAGS="" LIBS="" LN_S="ln -s" NM="/usr/bin/nm -p" RANLIB=":" STRIP="strip"
lt_INSTALL="/home2/src/gnu/libtool-2.x/libltdl/config/install-sh -c" OBJEXT="o"
EXEEXT="" SHELL="/bin/ksh" CONFIG_SHELL="/bin/ksh" CXX="CC" CXXFLAGS="-g"
CXXCPP="CC -E" F77="" FFLAGS="" FC="" FCFLAGS="" GCJ="" GCJFLAGS="-g -O2"
_lt_pkgdatadir="/home2/src/gnu/libtool-2.x"
LIBTOOLIZE="/usr/local/src/gnu/libtool-2.x/libtoolize"
LIBTOOL="/usr/local/src/gnu/libtool-2.x/libtool"
tst_aclocaldir="/home2/src/gnu/libtool-2.x/libltdl/m4" -k "simple
minumum ver of m4?
Is there a miniumum version of m4 to build/test libtool-2.2.6 and later? Thanks. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Solaris 10 w/ SunStudio 11 64bit mode
Hi Ralf, On Mon, 11 Feb 2008, Ralf Wildenhues wrote: > * Tim Rice wrote on Mon, Feb 11, 2008 at 06:23:59AM CET: > > CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008 > > Solaris 10 w/ SunStudio 11 > > > > I'm seeing failures in 64 bit mode I don't see in 32 bit mode with > > compiler options that woked for me in both 32 & 64 on branch-1.5. > > testsuite.log-64.gz attached. > > Please try again, with making the f95 compiler generate 64bit code: > FCFLAGS="-xtarget=ultra -xarch=v9" > > assuming those are the right options. $FFLAGS is for $F77, $FCFLAGS is > for $FC, and needed in this case. (Libtool currently doesn't support > having two different-language compilers do different ABIs.) I didn't expect it to work with diifferent ABIs I thought I had what I needed with FFLAGS="-xtarget=ultra -xarch=v9" Thanks for the FCFLAGS tip, that worked. Tests pass now. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Solaris 10 w/ SunStudio 11 64bit mode
CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008 Solaris 10 w/ SunStudio 11 I'm seeing failures in 64 bit mode I don't see in 32 bit mode with compiler options that woked for me in both 32 & 64 on branch-1.5. testsuite.log-64.gz attached. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] testsuite.log-64.gz Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS HEAD test 30
On Sun, 10 Feb 2008, Ralf Wildenhues wrote: > [ cutting libtool-patches ] > > Hi Tim, > > * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET: > > Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on > > UnixWare 7.1.4. There is still some work needed on templates on UnixWare > > but nothing that should hold up this release. > > Was that because of this rule and the compiler not understanding -c -o? No that's only a problem with UnixWare 2.x native compilers > > | cpp.o: > | $(CXXCOMPILE) -c -o $@ $< > > Otherwise, I don't have a report for this on my radar, so I'd appreciate > if you could post the testsuite.log for the failures. testsuite.log.gz attached. The thread started in libtool on Wed, 28 Sep 2005 with the Subject: forward porting UnixWare fixes to HEAD and on Fri, 11 Nov 2005 you moved it to libtool-patches, same subject. Basicly I have not semt any time to get those tests working. > > Thanks, also for confirming the other fix, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] testsuite.log.gz Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS HEAD test 30
On Fri, 8 Feb 2008, Ralf Wildenhues wrote: > * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: > > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite > > on my UnixWare 7.1.4 box. > > Thanks for the bug report. I've installed this patch. > 2008-02-08 Ralf Wildenhues <[EMAIL PROTECTED]> > * tests/archive-in-archive.at Thanks Ralf, that worked. Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on UnixWare 7.1.4. There is still some work needed on templates on UnixWare but nothing that should hold up this release. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
CVS HEAD test 30
I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite on my UnixWare 7.1.4 box. A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is attached. I don't seem to understand the new test suite well enough to figure this out. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]# -*- compilation -*- 30. archive-in-archive.at:26: testing ... + cat + 1> foo.c 0<< + cat + 1> bar.c 0<< + cd . + pwd + thisdir=/usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o foo.lo foo.c libtool: compile: cc -g -c foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -g -c foo.c -o foo.o >/dev/null 2>&1 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o bar.lo bar.c libtool: compile: cc -g -c bar.c -KPIC -DPIC -o .libs/bar.o libtool: compile: cc -g -c bar.c -o bar.o >/dev/null 2>&1 + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libfoo.la foo.lo -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: link: ar cru .libs/libfoo.a foo.o libtool: link: : .libs/libfoo.a libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" ) + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libfoo.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: cp .libs/libfoo.lai /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.la libtool: install: cp .libs/libfoo.a /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: chmod 644 /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: : /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a -- Libraries have been installed in: /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-R,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libbar.la bar.lo ./libfoo.a -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 *** Warning: Linking the shared library libbar.la against the *** static library ./libfoo.a is not portable! libtool: link: ar cru .libs/libbar.a ./libfoo.a bar.o UX:ar: ERROR: ./libfoo.a is in archive format - embedded archives are not allowed + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libbar.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: `libbar.la' is not a valid libtool archive libtool: install: Try `libtool --help --mode=install' for more information. /opt/src/gnu/libtool-2.x/tests/archive-in-archive.at:48: ar -t libbar.a | grep libfoo.a + grep libfoo.a + ar -t libbar.a stderr: UX:ar: ERROR: Archive libbar.a not found stdout: + ar -t libbar.a UX:ar: ERROR: Archive libbar.a not found + archive_contents='' 30. archive-in-archive.at:26: 30. static library contains static library (archive-in-archive.at:26): UNEXPECTED PASS(sys0m0.23s) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5.23b
On Sun, 18 Feb 2007, Ralf Wildenhues wrote: > Hello Tim, > Tim Rice writes: > > > > Should a single libtool handle both 32bit & 64bit builds on Solaris > > with Sun Studio 11? > > No. [snip] > Also please note the multilib fixes that are new in 1.5.23b are specific > to GCC. OK, I'll continue to build 2 versions of libtool. Thanks. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 1.5.23b
Should a single libtool handle both 32bit & 64bit builds on Solaris
with Sun Studio 11?
I tried using it to build libiconv-1.10 and got
.
cd src && gmake all
gmake[1]: Entering directory `/usr/local/src/gnu/libiconv-1.10/src'
/bin/sh ../libtool --mode=link cc -L/opt/lib/64 iconv_no_i18n.o ../srclib/libicr
t.a ../lib/libiconv.la -o iconv_no_i18n
cc iconv_no_i18n.o -o .libs/iconv_no_i18n -L/opt/lib/64 ../srclib/libicrt.a ../
lib/.libs/libiconv.so -R/opt/lib/64
ld: fatal: file iconv_no_i18n.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to .libs/iconv_no_i18n
gmake[1]: *** [iconv_no_i18n] Error 1
gmake[1]: Leaving directory `/usr/local/src/gnu/libiconv-1.10/src'
gmake: *** [all] Error 2
.
The 64 bit configure line looks like this.
:
PACKAGE=libiconv
DIR=gnu
VER=1.10
ID=/usr/xpg4/bin/id \
CFLAGS="-fast -xtarget=ultra -xcode=pic32 -xarch=v9" \
CPPFLAGS="-I/opt/include" \
LDFLAGS="-L/opt/lib/64" \
/opt/src/${DIR}/${PACKAGE}-${VER}/configure \
--prefix=/opt/mt/${PACKAGE}-${VER} \
--libdir=/opt/lib/64\
--mandir=/opt/mt/${PACKAGE}-${VER}/man \
--enable-shared \
2>&1 | tee x.conf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Help: 64 Bit Solaris 10
On Mon, 5 Dec 2005, Edward Maros wrote: > This may be a frequent question, but I have not been able to find a > solution yet. I am trying to port out application to 64bit using a > sparc4u running Solaris 10. The application uses > autoconf/automake/libtool/gcc for configuration and building of targets. > With my first attempt at going 64 bit, I hit a problem since libtool > seems to configure only 32bit (at least for creating shared objects). Am > I missing something that I could do to make the leap to 64 bit? Try CC="gcc -m64" ./configure .... > > Thanks, > Ed > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: > D??a ??t 17. November 2005 19:46 Tim Rice nap??sal: > > > > [EMAIL PROTECTED] peto]$ libtool --version > > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > > [EMAIL PROTECTED] peto]$ libtool --config |more > > > > > > # Libtool was configured on host hp6.mandrakesoft.com: > > > > > > [snip] > > > > > [EMAIL PROTECTED] peto]$ su > > > Password: > > > [EMAIL PROTECTED] peto]# libtool --version > > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > > > [EMAIL PROTECTED] peto]# libtool --config |more > > > > > > # Libtool was configured on host chello082119109251.chello.sk: > > > > You have 2 different versions of libtool on your system. > > When you "su" you get a different PATH. > > Remove the one you don't want or fix your PATH aftr you "su". > > Thank you, it works in confif but it does not realy produce shared libraries > yet. my local version in /usr/local was made from sources and MDK vesrion > works but not correctly (with freetype) Version 1.4.3 is a bit old. You might want to try 1.5.20. > > > Peter > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: > Dear conference, > > During compilation of the OO.org 2.0 in Mandrake 9.0 I found that libtool > 1.4.3 shows > > [EMAIL PROTECTED] peto]$ libtool --version > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > [EMAIL PROTECTED] peto]$ libtool --config |more > > # Libtool was configured on host hp6.mandrakesoft.com: [snip] > [EMAIL PROTECTED] peto]$ su > Password: > [EMAIL PROTECTED] peto]# libtool --version > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) > [EMAIL PROTECTED] peto]# libtool --config |more > > # Libtool was configured on host chello082119109251.chello.sk: ^^^ [snip] > > Can anyone recomend me what to do to work libtool as root for shared > libraries > because OO.org 2.0 dmake(nmake) works only as root.,please.. You have 2 different versions of libtool on your system. When you "su" you get a different PATH. Remove the one you don't want or fix your PATH aftr you "su". > > > Thank you for any help as well as finding problem which can be also in path > I look forward hearing from you > > Yours faithfully > > Peter Fodrek > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEAD test 13
On Sun, 30 Oct 2005, Tim Rice wrote: > . > 13. old-m4-iface.at:34: testing ... > libtoolize: linking file `./config.guess' > libtoolize: linking file `./config.sub' > libtoolize: linking file `./install-sh' > libtoolize: linking file `./ltmain.sh' > libtoolize: You should add the contents of > `/opt/src/gnu/libtool-2.x/libltdl/m4/libtool.m4' to `aclocal.m4'. > old-m4-iface.at:79: $AUTOCONF --force > stderr: > UX:ksh: ERROR: autoconf: not found > stdout: > old-m4-iface.at:79: exit code was 1, expected 0 > 13. old-m4-iface.at:34: 13. AM_PROG_LIBTOOL (old-m4-iface.at:34): FAILED > (old-m4-iface.at:79) > . > > Should test 13 fail if the system you are testing on has no autoconf? > Perhaps it should pass. Same for 14, 27, & 28 And aclocal in 14, 21, 22, 23, 27, & 28 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
HEAD test 13
. 13. old-m4-iface.at:34: testing ... libtoolize: linking file `./config.guess' libtoolize: linking file `./config.sub' libtoolize: linking file `./install-sh' libtoolize: linking file `./ltmain.sh' libtoolize: You should add the contents of `/opt/src/gnu/libtool-2.x/libltdl/m4/libtool.m4' to `aclocal.m4'. old-m4-iface.at:79: $AUTOCONF --force stderr: UX:ksh: ERROR: autoconf: not found stdout: old-m4-iface.at:79: exit code was 1, expected 0 13. old-m4-iface.at:34: 13. AM_PROG_LIBTOOL (old-m4-iface.at:34): FAILED (old-m4-iface.at:79) . Should test 13 fail if the system you are testing on has no autoconf? Perhaps it should pass. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
HEAD tests
Is it intentional that the new test suite only gets run if the old test suite passes? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tagdemo test / -c -o
On Sun, 30 Oct 2005, Ralf Wildenhues wrote: > Hi Tim, > > * Tim Rice wrote on Sun, Oct 30, 2005 at 02:34:18AM CET: > > On Sun, 30 Oct 2005, Ralf Wildenhues wrote: > > > I guess you should be able to use this manually-written rule as a > > > workaround: > > > > > > .cpp.$(OBJEXT): > > > $(CXXCOMPILE) -c $< > > > > Or this patch to automake > > .. > > --- automake-1.9.6/automake.in.old 2005-06-30 14:17:13.0 -0700 > > +++ automake-1.9.6/automake.in 2005-10-29 18:31:51.565961323 -0700 > > @@ -691,7 +691,6 @@ > >'compile' => '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) > > $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', > >'compiler' => 'CXXCOMPILE', > >'compile_flag' => '-c', > > - 'output_flag' => '-o', > >'libtool_tag' => 'CXX', > >'lder' => 'CXXLD', > >'ld' => '$(CXX)', > > No. :) > > Above workaround works only because > - we do not use subdir-objects; in fact, we do not use subdirs at all, > - none of the non-libtool objects (i.e., the `.o' ones) use per-target > flags It seems strange that automake's COMPILE section has no 'output_flag' => '-o', but the CXXCOMPILE does. > > It's really just appropriate for the tagdemo case, not for Automake in > general. > > Cheers, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tagdemo test / -c -o
On Sun, 30 Oct 2005, Ralf Wildenhues wrote: > Sorry for self-reply. > > * Ralf Wildenhues wrote on Sun, Oct 30, 2005 at 02:08:14AM CET: > > * Tim Rice wrote on Sun, Oct 30, 2005 at 01:41:22AM CEST: > > > > > > The native c/CC compilers on the that machine does not like -c -o > > > Is there a way to work around this, or is this an automake 1.9.6 bug? > > > > Oops. Does it work if you change the AC_PROG_CC_C_O to be > > AM_PROG_CC_C_O in libtool-1.5/tagdemo/configure.ac and rerun bootstrap? > > Gah. AM_PROG_CC_C_O is C only, not C++. > I guess you should be able to use this manually-written rule as a > workaround: > > .cpp.$(OBJEXT): > $(CXXCOMPILE) -c $< Or this patch to automake .. --- automake-1.9.6/automake.in.old 2005-06-30 14:17:13.0 -0700 +++ automake-1.9.6/automake.in 2005-10-29 18:31:51.565961323 -0700 @@ -691,7 +691,6 @@ 'compile' => '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler' => 'CXXCOMPILE', 'compile_flag' => '-c', - 'output_flag' => '-o', 'libtool_tag' => 'CXX', 'lder' => 'CXXLD', 'ld' => '$(CXX)', .. > > or this (uses undocumented Automake knowledge, thus not advised): > tagdemo_OBJECTS = tagdemo.lo > > Reminder to self (or whoever else): Automake needs to learn that C++ > and Fortran 77/90 compilers may not understand `-c -o'. > > Cheers, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
tagdemo test / -c -o
branch-1-5 I'm getting falures in the tagdemo-exec tests on my UnixWare 2.03 box because of this rule in tagdemo/Makefile.in . cpp.o: $(CXXCOMPILE) -c -o $@ $< . The native c/CC compilers on the that machine does not like -c -o Is there a way to work around this, or is this an automake 1.9.6 bug? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 1.5.22 ?
On Sun, 30 Oct 2005, Peter O'Gorman wrote: > Ralf Wildenhues wrote: > > > I should be able to post all outstanding 1.5 stuff within the next, say, > > three days. OK? > > Sure. Don't hurry, just that I was a little surprised by the number of changes > in branch-1-5 and figured that a new release would be a good idea. A more > complete release is an even better idea :) I'm doing some testing on some patches from Kean Johnston that has made improvements on my UnixWare patch and made big improvements on OpenServer 5. I'd like to see them in the next release. I suspect Kean will not be able to post them to libtool-patches before monday or tuesday. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
forward porting UnixWare fixes to HEAD
-o sub/main
$main_o lib2/libb.la lib/liba.la
stderr:
prelink: INFO: C++ prelinker: executing: CC -c -I../src/lib -I../src/lib2
-g -osub/main.o ../src/sub/main.cpp
Undefined first referenced
symbol in file
b(T1 &) [with T1=bs, return type=unsigned int] libb.a(b.o)
UX:ld: ERROR: Symbol referencing errors. No output written to sub/main
stdout:
libtool: link: CC -g -o sub/main sub/main.o lib2/.libs/libb.a lib/.libs/liba.a
template.at:214: ./sub/main; lt_status=$?; if test $lt_status -eq 0; then :;
elif test "X$host" != "X$build" && \
{ test -x "./sub/main" || test -x "./sub/main"$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
0a1
> UX:ksh: ERROR: ./sub/main: not found
19. template.at:115: 19. template test with subdirs (template.at:115): FAILED
(template.at:214)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
On Tue, 27 Sep 2005, Ralf Wildenhues wrote: > Hi Tim, > > * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST: > > I'd like to be able have the embedded runpath be /opt/lib even > > if I install in /opt/foo/lib. (the package posinstall script would put > > symbolic links in /opt/lib) > > I believe that should be possible now, although in a bit weird way: > configure --prefix=/opt --enable-fast-install [OPTIONS] > make > make install DESTDIR=/tmp > $mkdir_p /opt/foo > mv /tmp/opt/* /opt/foo > # create symlinks .. > ./libtool --mode=finish /opt/lib > (surely you can also use some other path below /opt as DESTDIR to avoid > another copy if /tmp is on another mount point). Hmm, that may work. I'll have to try it sometime. It'll require some serious changes to my package build scripts. :-( Thanks. > > Did I miss anything? > > Cheers, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR (was Re: static vs. dynamic linking)
On Tue, 27 Sep 2005, Howard Chu wrote: > First of all, my objective - other folks may have their own objectives > different than this: Build a suite of software that uses shared libraries, > such that any embedded runpaths only reflect the ultimate install path (e.g. > /opt/foo/lib) and not any of the build paths (e.g. ~/src/project1/blah). > I'd like to be able have the embedded runpath be /opt/lib even if I install in /opt/foo/lib. (the package posinstall script would put symbolic links in /opt/lib) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool generated for tests
branch-1-5 Could someone explain why the libtool generated in the test dirs are different than the one in the build dir? Or more importanbtly, why a software package using ltmain.sh from 1.5.21a would build a libtool that didn't work but copying libtool from my libtool build dir would work. The differences looked similar to the ones below. --- depdemo/libtool 2005-09-26 16:03:23.949817104 -0700 +++ libtool 2005-09-26 15:57:57.144777437 -0700 @@ -1,7 +1,7 @@ #! /bin/ksh # libtoolT - Provide generalized library-building support services. -# Generated automatically by (GNU depdemo 0.1) +# Generated automatically by (GNU libtool 1.5.21a (1.1220.2.300 2005/09/25 07:37:09)) # NOTE: Changes made to this file will be lost: look at ltmain.sh. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 @@ -53,7 +53,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -70,7 +70,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -159,10 +159,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown @@ -6896,7 +6896,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -6913,7 +6913,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -7002,10 +7002,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
annoying build environment
CVS HEAD Is there any reason not to have ltmain.in in the source tree at configure time and generate ltmain.sh (from ltmain.in) in the build tree? I have UnixWare, OpenServer, Solaris and Linux (each with multiple versions) here. I prefer to build from a NFS read-only source tree so I can test whatever change I make on multiple platforms while having to maintain only 1 source tree. I'd like to be able to make a change in the source tree, run bootstrap, then cd /some/build/dir, configure, make and not have it try to generate some file in the source tree. We can't do this now. But is this possible with the current design of CVS HEAD? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
