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

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

problem with nm check on recent Digital/Tru64 UNIX...

enerate the OS version of Tru64 5.x: it always comes up with `osf5.0' instead of `osf5.0', because the code in config.guess is only running `sizer' for the 4.x OS release. I'm not sure who's maintaining the canonical config.guess -- if someone know's I'll report t

Re: problem with nm check on recent Digital/Tru64 UNIX...

In regard to: Re: problem with nm check on recent Digital/Tru64 UNIX...,...: >On Aug 24, 2000, Tim Mooney <[EMAIL PROTECTED]> wrote: > >> If I change the egrep to > >> egrep '(/dev/null| object)' > >Thanks, I've just installed a variant of you

Re: AIX 4.3 and cvs libtool

And glancing at libtool.m4, the >same might apply on osf[345].) I believe you're right. I've run into the same problem at various times with libtool my our Digital/Tru64 UNIX boxes (4.x and 5.x). Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Ser

Re: dlopen on Solaris compared with IRIX/Tru64

t at least through 5.0 the RPATH in a shared library is not used to find shared libraries that are explictly dlopened by a program. I had a Compaq loader engineer explain it to me one time, it's somewhat complex. They expect to change that behavior in the future, from wh

[Fwd: libtool problem with linking .a's]

>>>>> "Tim" == Tim Heath <[EMAIL PROTECTED]> writes: Tim>I am getting the message: Tim> libtool: link: cannot build libtool library `liboracle.la' from Tim> non-libtool objects: /opt/oracle/X/product/8.1.6/lib/libcore8.a Tim> Does any

Re: libtool on solaris and hard coding the rpath

library. You do know about the LD_RUN_PATH environment variable that the Solaris linker will honor, though, right? You could use that to hardcode your DT_RPATH with `libtool' being none the wiser, I think. Tim ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool on solaris and hard coding the rpath

;encoded. That is correct, but the idea is you set it right before you build the program, and don't keep it around afterward, unless you have just a few standard directories that need to be searched, in which case you might be lazy and just leave it in your environment all the time. With S

Re: Porting question (HP-UX on IA64)

I'm looking at ltconfig for libtool 1.3.5, even that far back there was good support for doing what you're trying to do. Search for libsuff in ltconfig from 1.3.5, to find the section I'm talking about. Tim -- Tim Mooney [EMAIL PROTECTED] In

Re: 1.3e (1.910) test results for alpha-dec-osf4.0f (PASS)

? With that change in place, using gmake check now works. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) N

libtool 1.4 README patch

With these two items from the announcement: * Improved support for darwin (rhapsody), mingw32, NetBSD, Compaq Tru64 V5.0 and Digital Unix V4.*. ... * Support for aix5*. and my understanding of the very recent changes related to AIX (including AIX 5), coupled with the version numberin

Re: a small C warning

so the compiler is assuming it returns an int. error is apparently some type of pointer, right? The assignment your doing is taking the *assumed* int return value from the function call and converting it into the required pointer type. What you need to do is make sure there's a prototype for

libtool-1.4b bootstrap nit

e 1.4-p4. Are the syntax errors from configure something peculiar about my environment, or do other people see them too? Also, the patch below my sig might be useful for bootstrap (the problem I'm describing above happens with or without it, though, so the patch is unrelated). Tim -- Tim

Re: libtool-1.4b bootstrap nit

In regard to: Re: libtool-1.4b bootstrap nit, Gary V. Vaughan said (at...: >On Wednesday 11 July 2001 1:17 am, Tim Mooney wrote: >> >> If I grab the tarball from alpha.gnu.org and untar it and then >> >> ./bootstrap > >No need to bootstrap it yoursel

Re: libtool-1.4b bootstrap nit

In regard to: Re: libtool-1.4b bootstrap nit, Gary V. Vaughan said (at...: >Excellent bug report Tim! Although unable to reproduce the bug with my >shells, I have committed the attached patch, which I think will fix the >problem for you. Thanks, that did fix it. Tim -- T

question about AC_LTDL_SYS_DLOPEN_DEPLIBS

I'm not 100% sure I know what whether deplibs are loaded by dlopen means. Does it mean: If you explicitly load a shared object via dlopen(), are any shared objects that it depends on loaded for you automatically? Or am I misinterpreting? Tim -- Tim M

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: >On Thursday 12 July 2001 8:12 pm, Tim Mooney wrote: >> I'm not 100% sure I know what >> >> whether deplibs are loaded by dlopen >> >> means. Does it mean: >> >>

libtool 1.4b problem on HP-UX

the AC_PROG_CC would probably work, but it's a hack. Someone more familiar with the entire configuration process could probably come up with a better way of doing this. If not, I would be happy to submit a patch that does the test above, for configure.ac for both libto

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Robert Boehne...: >> I think the enclosed patch should be correct, for at least recent versions >> of both Tru64 and IRIX. >> >> Tim > >Tim: > >I added AIX to your list and wrote a test program to

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

that honoring RPATH in libraries is coming to a future version of Tru64, but it's not here yet. I summarized about this issue on the tru64-unix-managers mailing list several months back. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

bad. 4.x and earlier also have a horrible XPG conformance issue with restartable signals, and the fix for that (in 5.x) also won't be backported. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Bui

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

ins, though: what about platforms that have a different API for dynamic loading, e.g. HP-UX < 11.x? Does this cache value (or these cache values) apply there as well, even though the system uses shl_load instead of dlopen()? Tim -- Tim Mooney [EMAIL PROTECTED] Info

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

llective knowledge about the >architectures in the code instead of in comments. Ok, I'm working on it. I'll have a patch later today or tomorrow. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

h to perform the test *instead* of >listing values for only hosts triplets that have been researched... :-) For now, what do you think of the updated patch, below? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Ro

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

omewhere to add it to the >distribution presently. I added some notes to libtool.texi about the issue. I'll send the patch to the libtool-patches list. Take a look, and see what you think. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology

Re: use of __STDC__ in libtool.m4 on HEAD

TDC__) && !__STDC__ What happens if __STDC__ is 1 (as it should be for strict ANSI conformance)? I think Albert's suggestion of dropping the && ... is the right one. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701

Re: ltdl.c and 1.4.1 (type conflicts)

ed to compile libtool with a pre-ANSI compiler. This may not sit well with the gcc people, as we may get into a chicken-or-the-egg problem there. I don't know. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 23

Re: ltdl.c and 1.4.1 (type conflicts)

cult, so I have no problem at >all with doing it. As long as it's not a problem for you, great! Hopefully it never becomes an issue. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-

Re: ltdl.c and 1.4.1 (type conflicts)

In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Gary V. Vaughan said...: >P.S. Tim, your return address does not exist according to DNS... I'm >removing the hostname part for this message incase that works. I'm not sure how that happened, but nothing's changed on my

Re: ltdl.c and 1.4.1 (type conflicts)

In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Bruce Korb said (at...: >Tim Mooney wrote: > >> Something similar to what's done on page 147 (section 6.7) of K&R2e -- > >K&R2e == ANSI > >> Of course, most of the functions still use the K&R

Re: libltdl & 64-bit lint

oints to. Instead, define a struct or a union that has members of the appropriate type (pointer to an function with the right type, or a pointer to the right struct type, or whatever else the function needs to be able to return), and then return a pointer to that struct (or union). That way you&#

Re: Libtool error

libtoolize --copy --force aclocal autoconf Depending on the package and what you have installed on your box, more may be needed than just that. That's kind of a "big hammer" approach, though. Tim -- Tim Mooney [EMAIL PROTECTED] Information Tec

[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: [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

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

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

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

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

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

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

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

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

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

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-

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

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

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(

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

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

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

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

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?

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?

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?

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

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

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

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

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

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

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

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

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

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

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

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?

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?

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?

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?

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

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

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

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

  1   2   >