Re: Passing LD_RUN_PATH through to the linker

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

. 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

Re: Are *.la files supposed to be executable?

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 th

Re: Avoid -Wl,--whole-archive

On 5/16/19 5:00 PM, Bob Friesenhahn wrote: > On Thu, 16 May 2019, Tim Rühsen wrote: > >> Hi, >> >> at GNU Wget2 we are just splitting a (shared) library into several >> smaller ones, grouped by functionality. >> >> We depend on gnulib and have a single

Avoid -Wl,--whole-archive

PFLAGS = $(libwget_la_CPPFLAGS) libwget_progress_la_LIBADD = ../lib/libgnu.la libwget_progress_la_LDFLAGS = $(libwget_la_LDFLAGS) -no-whole-archive If wanted, I am willing to write a real patch (some hints what to consider would be nice - the codebase is currently unknown to me). Regards, Tim signature.as

Re: What happened to libtool transitive DSOs?

inst these libraries as well. To restore the previous behavior of ld, use the -copy-dt-needed-entries command-line option. (BZ#1292230) - end excerpt from RHEL release notes Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing &

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 |

Re: libtool-2.4.2.418 released [alpha]

stdout: ./libtool.at:120: exit code was 1, expected 0 21. libtool.at:60: FAILED (libtool.at:120) Let me know what other useful information I can provide. There's a patch after my signature that alters the README to provide the actual name of the log file from the test suite. Tim -- Tim Mooney

solaris recording name conflict when building newer versions of system libraries

ack my local copy of libtool to do that (and then re-libtoolize projects that run into this issue, so that they're using my hacked libtool), can anyone point me at places in the libtool source where I should look to make this change? Tim -- Tim Mooney

Re: [sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR

In regard to: Re: [sr #107416] relink with a DESTDIR install mistakenly...: On Fri, 2 Jul 2010, Tim Mooney wrote: This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. This does not seem to be a libtool bug

[sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR

URL: Summary: relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR Project: GNU Libtool Submitted by: enchanter Submitted on: Fri 02 Jul 201

Re: libtool-2 problem: Building a QT3 Designer plugin

I'm learning more about libtool, but maybe I should  have mentioned that this source tree is a bit old and  made for libtool-1. Still works Ok with LT2, except this one pesky widgets problem. I hate to remove something that worked, even if it's just  a plugin for QT3... Thanks

Re: libtool-2 problem: Building a QT3 Designer plugin

Unless my eyesight is going, it's in the second section only. Attached output of the two stages. Thanks. Tim. On Thursday 05 November 2009 10:12:47 pm you wrote: > On Thu, 5 Nov 2009, Tim wrote: > > With libtool-1, no problem, the single .so file > > is built and wor

libtool-2 problem: Building a QT3 Designer plugin

to libmusewidgetsplugin, to satisfy naming conventions. Thanks kindly. Tim. include $(top_srcdir)/common.am # musewidgetsplugin_so_CPPFLAGS = $(MUSECXXFLAGS) -fPIC -I.. -I$(top_srcdir)/synti \ # -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_PLUGIN #libmusewidgetsplugin_la_CPPFLAGS = $(MUSECXXFLAGS)

Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12

-prefix-dir option was added, which I believe happened early in the 1.5.x series. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) No

Re: cmdline_wrap.at

ep -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 Rice

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

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

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 &g

Re: Installed libs wrongly used on 64-bit Linux?

local/lib/64, rather than the version 1.1 libfoo.la that was just installed in e.g. /tmp/build/bar/usr/local/lib/64. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building

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: Multiple -rpaths

eeded, and those direct dependencies can cause headaches during upgrades? Tim -- Tim Mooney [EMAIL PROTECTED] Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State Univers

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

* [all-recursive] Error 1 By visual inspection, it doesn't look like the relevant code in libtool.m4 that automatically adds `-library=Cstd -library=Crun' has changed in any significant manner since 1.5.2X. Tim -- Tim Mooney [EMAIL PROTECTED] Information Te

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote: I think I have discovered a bug in libtool's link behavior with the Sun Workshop C++ compiler when creating a C++ library that requires libm. I obs

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: On Wed, 19 Mar 2008, Tim Mooney wrote: That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect

libtool C++ link bug with -lm functions with Sun Workshop compiler

stdeps,$1)='-library=Cstd -library=Crun' to _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun -lm' Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701)

Re: linking a C program with a C++ library on Solaris

In regard to: Re: linking a C program with a C++ library on Solaris, Ralf...: Hello Bob, Tim, * Bob Friesenhahn wrote on Tue, Feb 26, 2008 at 03:11:44AM CET: On Mon, 25 Feb 2008, Tim Mooney wrote: I don't see anything in 2.1b's info files or README or NEWS for updating a project

Re: linking a C program with a C++ library on Solaris

In regard to: Re: linking a C program with a C++ library on Solaris, Bob...: On Mon, 25 Feb 2008, Tim Mooney wrote: On Solaris, if you are linking against any C++ objects, you must use the C++ compiler to link. I don't know if that's common to other platforms or not, as I don

linking a C program with a C++ library on Solaris

kages that are primarily C (but link against C++ libraries/objects) to know that they need to "switch to" C++ for linking in their C project? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC

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 bi

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 Rice

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

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

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

Re: Sun Studio: STL libraries

u use CXXFLAGS="-library=%none -library=no%libC" Does libtool still thwart your efforts? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) Nor

Re: Sun Studio: STL libraries

In regard to: Re: Sun Studio: STL libraries, Tim Mooney said (at 6:05pm on...: In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Tim, you say we still need to have -library=Crun for the stlport4 case? More than likely, yes. The stlport4 incompatibili

Re: Sun Studio: STL libraries

In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Peter O'Gorman wrote: Tim Mooney wrote: In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...: Even with what Tim has pointed out I am seeing the contrary with the following:

Re: Sun Studio: STL libraries

In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:05pm...: I still maintain that it would be OK to have libtool automatically add `-library=Crun', since that is generally needed whether you're using -library=stlport4 or -library=Cstd, but it's OK to not include that. We jus

Re: Sun Studio: STL libraries

In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...: Even with what Tim has pointed out I am seeing the contrary with the following: o Open MPI src base o Sun Studio 12 o libtool 2.1b (just downloaded the latest) After autogen has finished the aclocal.m4 ends up

Re: Sun Studio: STL libraries

S, you probably also need -library=Crun since that won't automatically be added. I personally think that libtool should still be adding -lCrun automatically, as it does for -lc, since -lCrun is compatible with stlport4, but since there's a workaround, it's no big deal. Tim -- Tim Mo

Re: GMP: IBM mainframe build results

Ralf Wildenhues wrote: > * Tim Van Holder wrote on Tue, Jul 17, 2007 at 08:57:56AM CEST: > [...] >> Both compiles and links are affected. >> >> For the linking, automake puts the -o at the end itself, so it is >> at least partially to blame. Then again, libtool do

Re: GMP: IBM mainframe build results

Ralf Wildenhues wrote: > * Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST: >> Ralf Wildenhues wrote: >>>> - [LIBTOOL] by default, the compilers require that files come last on >>>> the command line, and many versions of libtool (including the on

Re: GMP: IBM mainframe build results

Ralf Wildenhues wrote: >> - [LIBTOOL] by default, the compilers require that files come last on >> the command line, and many versions of libtool (including the one >> included with GMP) break this rule when configure has determined -c >> and -o can both be used (it puts the -o last). To work

GMP: IBM mainframe build results

_value_table(int base)" method that returns the correct table (determining ASCII vs EBCDIC at runtime). With these changes (limits in mpf/t-get_d.c, and EBCDIC-friendly mp_dv_tab.c), the test results change to - top-level: 9/9 tests passed - mpn:9/10 tests passed - mpz: 53/56 test

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.

Libtool 1.5.23b

{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] _

Re: libtool insists on using shared library

report a bug to the packagers. Thanks for your (very quick!) help. grts Tim ___ http://lists.gnu.org/mailman/listinfo/libtool

libtool insists on using shared library

.0 it works as expected. grts Tim $ libtool --version ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: set flags based on compiler version?

In regard to: Re: set flags based on compiler version?, Ralf Wildenhues...: * Tim Mooney wrote on Fri, Jul 07, 2006 at 01:13:25AM CEST: Is there a recommended way to modify libtool (I'm looking at 1.5.22) such that PIC flags are set based on compiler *version*? Look at the output o

set flags based on compiler version?

x86*-*-solaris* with W/F/S compiler, any version: _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' If someone can provide some guidance on how to approach this, I'll send along a patch. Tim -- Tim Mooney [EMAIL PROTECTED] Information Tech

Re: LT_* equivalent to AC_CHECK_LIB?

o I'm much less aware of what goes on there. If I feel the need to dig any deeper on this (pretty doubtful at this point, you and Bob have completely disabused me of the notion that this is something I want to try help "solve"), I'll do the necessary digging in the arc

Re: LT_* equivalent to AC_CHECK_LIB?

In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Ralf Wildenhues said...: * Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST: So to address this, libtool would need to - know how the platform behaves regarding shared library dependencies - in the case of static libraries, continue

Re: LT_* equivalent to AC_CHECK_LIB?

In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...: On Mon, 3 Jul 2006, Tim Mooney wrote: I seem to recall discussion on this list in the past about why distributions were doing that, but I don't recall what any of the reasons were. Has any work (perhaps as pa

Re: LT_* equivalent to AC_CHECK_LIB?

why distributions were doing that, but I don't recall what any of the reasons were. Has any work (perhaps as part of libtool 2.0) gone into addressing the reason(s) why they were doing that? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Ser

Re: LT_* equivalent to AC_CHECK_LIB?

w of the platforms didn't. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __

Re: LT_* equivalent to AC_CHECK_LIB?

In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...: On Mon, 3 Jul 2006, Tim Mooney wrote: This seems like it should be an obvious question, but I'm not finding any obvious answers in either the libtool or autoconf documentation. Is there a libtool-aware equivale

LT_* equivalent to AC_CHECK_LIB?

ies is required to get libneon and its dependencies. If there's a libtool-aware equivalent macro, it would be so much easier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building

Re: No LT_GLOBAL flag in dlopen on debian?

Yeah, fair enough. :-)  Ok, thanks very much.   -Tim   On 6/1/06, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: On Thu, 1 Jun 2006, Tim Furlong wrote:> Hi Bob and Ralf,>> Thanks for your responses, that makes sense. Do you happen to know offhand > which platforms or families

Re: No LT_GLOBAL flag in dlopen on debian?

ice here in some way.  (No, I don't have a good idea.) Cheers,Ralf-- Tim Furlong[EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool

No LT_GLOBAL flag in dlopen on debian?

e-wide or on a per-module basis (perhaps I'm just not using -export-dynamic properly?)  If anyone could offer some insight, it would be greatly appreciated.  Please let me know if I can provide additional information about my system configuration that would be useful. Thanks, -Tim _

Re: Build shared library with shared libraries and static libraries on HP-UX

there's no easy way to guarantee that requirement with static libraries. - Is there a way to resolve this situation ? Manually build c-client as a shared library, or build c-client so that all object files are compiled as PIC and then hack libtool so that the checks for static librari

Re: handling of missing AR

you've swayed me over to your side now. It *might* be a good idea to AC_MSG_WARN if those things aren't found, but I no longer think it's a good idea to error out. Tim -- Tim Mooney [EMAIL PROTECTED] Informatio

Re: handling of missing AR

and shared libraries on multiple esoteric platforms, without the package author having to worry about the details of how it's done or whether the person running configure only wants one or the other type of libraries. The real question is, does libtool's configure macro know whether

Re: handling of missing AR

s, but sometimes ar is not needed, for example it /may/ not be needed when --disable-static is given. But if --disable-static is *not* given, shouldn't it be required? Shouldn't libtool's portion of configure fail in that case? Tim -- Tim Mooney [EMAIL PR

Re: libtool convenience libraries and C++ constructors

On Thu, 9 Mar 2006, Ralf Wildenhues wrote: Tim, Could we continue this discussion on a mailing list? For example [EMAIL PROTECTED] done. * Tim Janik wrote on Thu, Mar 09, 2006 at 10:41:37AM CET: On Thu, 9 Mar 2006, Ralf Wildenhues wrote: * Tim Janik wrote on Wed, Mar 08, 2006 at 10:17

Re: libtool convenience libraries and C++ constructors (fwd)

On Thu, 9 Mar 2006, Ralf Wildenhues wrote: Hi Tim, * Tim Janik wrote on Wed, Mar 08, 2006 at 10:17:22PM CET: looks to me (from peeking at the libtool mailing list), that you're one of the new maintainers now. Yes, that is true. i'm looking into getting libtool convenience li

Re: GNU Libtool 1.5.22 released.

In regard to: Re: GNU Libtool 1.5.22 released., Ralf Wildenhues said (at...: Hi Tim, Tim Mooney writes: In regard to: Re: GNU Libtool 1.5.22 released., Ralf Wildenhues said (at...: - I accidentally bootstrapped libtool-1.5.22 with CVS versions of Autoconf and Automake, instead of using 2.59

Re: GNU Libtool 1.5.22 released.

instead of ${prefix}/info Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

Re: Help: 64 Bit Solaris 10

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 .... >

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 --confi

Re: Differnet config for root and non root user

nk 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' > l

HEAD test 13

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 > > > worka

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 no

tagdemo test / -c -o

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 ?

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

Re: mode=link and full path to dependent shared library?

the gettext package, mainly lib-link.m4. It would be nice if configure's output matched what was actually going to be used, but that would involve changes to gettext's macros too. I'll report the LTLIBINTL issue to the aspell folks. Thanks Ralf and Albert for the adv

Re: mode=link and full path to dependent shared library?

In regard to: Re: mode=link and full path to dependent shared library?,...: On Wed, Oct 12, 2005 at 09:40:18AM -0500, Tim Mooney wrote: In regard to: Re: mode=link and full path to dependent shared library?,...: If so, shouldn't lib-link be producing that as deplib instead? I.e., a

Re: mode=link and full path to dependent shared library?

ve. I did notice that LTLIBINTL was correct (i.e. used -L/local/gnu/lib -lintl instead of /local/gnu/lib/libintl.so) but that's not what aspell was using (it's using LIBINTL). Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701)

Re: mode=link and full path to dependent shared library?

l/gnu/lib/libintl.so from the link for GNU libaspell.so. Thanks for the patch, it appears to be exactly what I needed! Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 23

Re: mode=link and full path to dependent shared library?

s vary, but maybe taking advantage of this is your intention? I more or less stumbled on this by accident, and was just trying to understand why libtool was removing the shared library that was specified by path. I assumed that the AM_GNU_GETTEXT was doing that for a reason. Tim -- Tim Mo

mode=link and full path to dependent shared library?

ut it's eliding the /path/to/lib/libdep.so from the shared library creation line. I'm just trying to find where this behavior is discussed, so I can understand why it's doing that. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services

forward porting UnixWare fixes to HEAD

itten 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 > > sy

Re: SYSROOT/DESTDIR (was Re: static vs. dynamic linking)

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(

libtool generated for tests

grams 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] ___

annoying build environment

ut is this possible with the current design of CVS HEAD? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool

possible 1.5.20 regression?

t Note that I normally build libtool with one local patch for Tru64, but I have verified that the test output is the same both with and without that patch. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-

Re: Call for help: Solaris C++ and Sun CC

ue. How about this? [patch elided] I think it's commit-worthy. It certainly helps outline the issue, and points to a source for more information for the people it impacts. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1

Re: Call for help: Solaris C++ and Sun CC

;good enough", I think, unless someone comes up with an easy way to guard against the issue. I suppose the test could be special-cased for Solaris, and ldd or some other tool used after linking to verify that a library we're expecting would show up on the list of NEEDED shared

Re: Call for help: Solaris C++ and Sun CC

There is no libCstd.so anywhere in /opt/SUNWspro/lib. I missed earlier parts of this thread, so I'm not sure what's being discussed. We do have the Workshop 6u2 environment, including the C++ compiler. I've never (manually) created these links or the links for libiostream

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

need it quoted: 05:00 PM dogbert ~$PS1='$ ' /bin/sh $ echo Xbla | sed 1s,^X,, X,,: not found $ sed: Function 1s, cannot be parsed. $ exit Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC B

Re: ksh bug on Tru64 UNIX causes current libtool failure

C API than say AIX or IRIX, and I think HP-UX has only recently caught up some. I've always found it easier to port to Tru64 than the aforementioned platforms. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 2

Re: ksh bug on Tru64 UNIX causes current libtool failure

In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: On Wed, May 18, 2005 at 05:34:45PM -0500, Tim Mooney wrote: In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: And for possible workarounds: Does Tru64 ship another shell suitable for use as

Re: ksh bug on Tru64 UNIX causes current libtool failure

x27;m not sure if it's "suitable"; hopefully libtool's configure can determine that? As I recall, that's been available since version 4.0, so it's not an option for version 3.2g and earlier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Te

versioning documentation

w its normally name.major, and how this relates to libtool's concept of the library's version. Thanks, Tim ___ http://lists.gnu.org/mailman/listinfo/libtool

OSF versioning and large current/revision/age

ehavior. I had been considering an environment variable that libtool would check and parse, but if other optional behavior control is going to be via command-line flags, it would seem best if my patch piggybacked on that work. Comments and suggestions welcome, Tim -- Tim Mooney

Re: GNU Libtool 1.5.8 released.

ns should be is less clear, especially since there will be differences in what's available for different platforms and OSes. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building

  1   2   >