[patch #9687] bugfix: make -export-dynamic imply --whole-archive

Follow-up Comment #2, patch #9687 (project libtool): Well, it's now 3 years later, and my memory of details on this is pretty much gone, but let's try. No warranty on anything here, I'm trying to reconstruct. [comment #1 comment #1:] > Could you maybe elaborate on your use case? Perhaps there's

[PATCH] hppa64-hpux11: Add +nodefaultrpath option to archive_cmds

As on ia64, we need to add the +nodefaultrpath ld option when using the HP linker on hppa64. Without this option, we end up with the default rpath settings in the embedded search path. Often, this results in path references to build locations, particularly when libtool doesn't use the +b

[patch #9687] bugfix: make -export-dynamic imply --whole-archive

URL: Summary: bugfix: make -export-dynamic imply --whole-archive Project: GNU Libtool Submitted by: equinox Submitted on: Tue 04 Sep 2018 01:56:34 PM CEST Category: None

Re: [PATCH 2/2] AIX: Stop exporting any _GLOBAL__ symbol.

ted from shared libraries, or exception > handling may break for applications with runtime linking enabled. Yes, another corner case that needs to be excluded. Thanks, David > --- > m4/libtool.m4 | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/m4/libtool.m4 b/m4/libtool.m

Re: [PATCH 1/2] Use POSIX nm to simplify AIX export_symbols_cmds.

On Mon, Mar 21, 2016 at 4:49 AM, Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com> wrote: > > On 03/20/2016 01:04 AM, David Edelsohn wrote: >> I agree with this in principle, but I'm not convinced that the patch >> itself is correct. > > Thanks! >

Re: [PATCH 1/2] Use POSIX nm to simplify AIX export_symbols_cmds.

t; weak" } { print $ 3 kw }'\'' you're starting and ending with '\" which seems odd. why aren't these complementary? Thanks, David On Wed, Mar 2, 2016 at 11:19 AM, Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com> wrote: > * m4/libtool.m4 (LT_PATH_NM): Detect POSIX-compatible

[PATCH, PING] Export AIX TLS symbols

Ping. Libtool export_symbols_cmds needs an update to recognize and export TLS symbols on AIX. http://lists.gnu.org/archive/html/libtool-patches/2015-11/msg0.html Thanks, David

Export AIX TLS symbols

ols_cmds) [AIX]: Add global TLS "L" symbols. Thanks, David LL Description: Binary data

Re: Running an uninstalled executable

El Tue, 12 May 2015 11:38:42 +0200 Alberto Luaces alua...@udc.es escribió: Hello, in an autoconf+automake+libtool C++ project containing only one program, I want to run the executable before installing it. Reading the manual I thought that it could be done with libtool --mode=execute

Re: Fwd: Fwd: android support

Hello, Glad seeing this being addressed :-) On Tue, Sep 10, 2013 at 12:41 AM, Brooks Moses bmo...@google.com wrote: Hello, Marco, Thanks for pinging this -- I'm trying to work through some of the libtool patch backlog, and I'll have a look at this in the next few days. I note that David

Re: Avoid exporting of internal symbols

El Martes, 5 de marzo de 2013 18:53:37 Satz Klauer escribió: __attribute__ ((visibility (default))) And why not __attribute__ ((visibility (hidden))) for symbols you don't want to be exported and __attribute__ ((visibility (default))) for the ones you want to be exported? You can also define

Re: Avoid exporting of internal symbols

I cant remember now the syntax, but maybe the gcc hidden visibility attribute is what you are looking for. El 04/03/2013 08:06, Satz Klauer satzkla...@googlemail.com escribió: I'm creating a shared library using libtool: libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused

AIX PIC shared library support

? Thanks, David * m4/libtool.m4 (_LT_COMPILER_PIC): Add -fPIC to GCC and GXX for AIX. diff --git a/m4/libtool.m4 b/m4/libtool.m4 index a8ecbc3..d0a5577 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -3874,6 +3874,7 @@ m4_if([$1], [CXX], [ # AIX 5 now supports IA64 processor

RE: Help needed to build shared library with libtool

Hi Peter I have tried using just g++ (no libtool) and the link succeeds. On this occasion it seems easiest for me just not to use libtool. Thanks for your help and advice. Best regards David ___ https://lists.gnu.org/mailman/listinfo/libtool

Help needed to build shared library with libtool

David ___ https://lists.gnu.org/mailman/listinfo/libtool

Help needed to build shared library with libtool

? Best regards David ___ https://lists.gnu.org/mailman/listinfo/libtool

Help needed to build shared library with libtool

? Best regards David ___ https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

] Error 1 David ___ https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

libGUI.so Well that would be fine. We just need to build for Linux. To be honest I don't know why we are using libtool. I will try just using g++ ... Thanks again David ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: [PATCH] libtool -- don't print warnings with --silent

On 5-Sep-11, at 12:08 PM, Peter O'Gorman wrote: I pushed this patch on Saturday. Thanks. Dave, I've attached an approximation of what the patch would do to gcc's ltmain.sh and an addition to boehm-gc's .exp file. Both completely untested, of course :-) I'll give this patch a try in

[PATCH] libtool -- don't print warnings with --silent

The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11. Without it, libtool always generates an informational warning when linking causing the entire boehm-gc testsuite to fail. Ok? Ralf would you please install in libtool tree if ok. 2011-07-09 John David Anglin dave.ang

Re: 32/64 bit on sun4u

On 02/16/11 05:46 PM, Patrick Welche wrote: On another list a poster thought that libtool was doing the wrong thing(tm), but it seems to be rather that config.guess needs to be given hints about sun4u. This means that this probably isn't the right list - but which one is? Essentially, he is

Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

On Sun, 19 Dec 2010, Ralf Wildenhues wrote: Sorry for the delay, I really would like to test the patch on the Libtool tree on a couple of systems, and write a Libtool testsuite addition for it, so we don't regress in the future. I hope to get to it before the end of the calendar year. If

ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

Ping. On Fri, 10 Dec 2010, John David Anglin wrote: On Sun, 28 Nov 2010, Ralf Wildenhues wrote: * John David Anglin wrote on Sun, Nov 28, 2010 at 09:42:43PM CET: The current relative path to libquadmath can be incorrectly interpreted on systems that hard code library paths

Re: [patch libgfortran] path to libquadmath

On Sun, 28 Nov 2010, Ralf Wildenhues wrote: * John David Anglin wrote on Sun, Nov 28, 2010 at 09:42:43PM CET: The current relative path to libquadmath can be incorrectly interpreted on systems that hard code library paths. In particular, on 32-bit hppa*-*hpux*, the '..' part of the path

Re: Linking problem building iconv on Solaris x86

On 08/29/10 10:27 AM, Ralf Wildenhues wrote: For others looking at the same issue: We hashed this issue out off-list, using configure CC='gcc -m64' works, just configure CFLAGS=-m64 fails. Cheers, Ralf Thank you Ralf. I had seen a similar issues with some other packages when

Link Time Optimization

I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. The problem is that I've tried git version of libtool (trunk) and still it is not supported since any program will compile with -flto (for example, mysql-5.1.50). Then, I have several

Re: Link Time Optimization

can.. Anyway, thanks for looking at this :) And only a suggestion, it would be usefull to have this posted somewhere (website for example...) to make searches better and avoid duplicate messages. David. ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Linking problem building iconv on Solaris x86

On 08/11/10 05:33 AM, Ralf Wildenhues wrote: * Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 11:33:36PM CEST: Hrmpf. On Solaris, we add '${wl}-z ${wl}text' to archive_cmds and archive_expsyms_cmds unconditionally, as opposed to only with -no-undefined. I wonder why that is the case

Linking problem building iconv on Solaris x86

I'm trying to build a 64-bit version of libiconv on Some Solaris machines. This works on all SPARC, and on 06/2009 release of OpenSolaris on an Intel Xeon. But I'm getting error messages at the link phase on two machines * Solaris 10 update 5 (released 05/2008) on x86 * OpenSolaris 11/2008 on

Re: Linking problem building iconv on Solaris x86

On 08/10/10 09:28 PM, Ralf Wildenhues wrote: /bin/bash ../libtool --mode=link gcc -m64 -fvisibility=hidden -o libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info 7:0:5 iconv.lo localcharset.lo relocatable.lo No, it does not. (sage subshell) fulvia:lib

Re: Linking problem building iconv on Solaris x86

On 08/10/10 10:10 PM, Ralf Wildenhues wrote: Hello David, * Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:48:25PM CEST: On 08/10/10 09:28 PM, Ralf Wildenhues wrote: /bin/bash ../libtool --mode=link gcc -m64 -fvisibility=hidden -o libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3

Problem when a 32-bit library is linked instead of a 64-bit library

On OpenSolaris, like Solaris, the default it to build 32-bit objects. For most applications, setting CFAGS=-m64 LDFLAGS=-m64 configure make works. However, one or two applications don't work well. In this case. http://trac.sagemath.org/sage_trac/ticket/7864 lists a build failure in the

Getting executable to link to libtool-built library

in tuxmath's Makefile.am, which fails with no rule to make libt4kcommon.la needed by tuxmath. However, I don't think LDADD is the correct approach here anyway. Anyone have any suggestions for the probably obvious step I'm missing? Thanks, David Bruce

Re: Getting executable to link to libtool-built library

Hello, On Mon, Dec 28, 2009 at 3:22 AM, Alberto Luaces alua...@udc.es wrote: David Bruce writes: Hello, I have two related programs (tuxmath and tuxtype) that share a lot of code in a human-maintained, copy-and-past fashion.  We have been working on moving the overlapping code

Re: Getting executable to link to libtool-built library

the definitions and rebuilt the library, I can link tuxmath to it. Anyway, if someone would confirm that AC_CHECK_LIB is the right way to do this, I would be a most appreciative libtool newbie. Thanks, David Bruce ___ http://lists.gnu.org/mailman/listinfo/libtool

RE: pr-msvc-support: building .DLLs with symbols

$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG' NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static That will not work (as you noticed) as it will send the -Wl, option stright to cl when configure tries w/o libtool. Is there any hope of this working one day?

RE: pr-msvc-support: building .DLLs with symbols

Here's a couple of patches that implements support for -Wl, and -Xlinker for MSVC. The first one (rename-dashL_envvar-tolinker_envvar.patch) is just a rename, to reduce confusion, and the second patch (-Xlinker-msvc.patch) contains the new code... Ok for the pr-msvc-support branch? I'm

RE: pr-msvc-support: building .DLLs with symbols

You want to send -DEBUG to link.exe, not to cl.exe. I'm sure you know this, but simply adding -DEBUG to LDFLAGS is not the way you do this. The correct way would be to use -Wl,-DEBUG. If the msvc stuff were complete, libtool would then feed -DEBUG to the linker. But this does not currently

RE: extra exports with libtool (pr-msvc-support)

I just tried this by adding libfoo_la_LDFLAGS += -export-symbols symfile and manually creating an empty file named symfile in the example I posted earlier. Now the only symbol that gets exported is the one decorated with dllexport. Thanks for the workaround. One more snag

pr-msvc-support: building .DLLs with symbols

Even when I set LDFLAGS to -DEBUG, I can't seem to get libtool to use that flag when building a dll. So, I want to get debug information into the .dll but it's not there. I verified that it's not there by looking at the output of dumpbin -all. Here's the libtool invocation and output for the

RE: extra exports with libtool (pr-msvc-support)

Indeed, good to know. Your input made me realize that it should be possible to work around the extra exports with something like -export-symbols-regex=probably_not_a_match or with an empty SYMFILE and -export-symbols=SYMFILE Untested though, but the linker should then pick up the symbols

extra exports with libtool (pr-msvc-support)

I'm running into a situation where libtool is exporting something I don't expect it to. I've attached a tarball that demonstrates this. So it's more clear what I'm talking about without having to dive into the attachment, I'm compiling a shared library that I think should have one export. But

RE: global_symbol_pipe not picking up an initialized globalvariable with msvc

UTL_EXPORT becomes __declspec(dllexport) when compiling the shared lib, __declspec(dllimport) when compiling the executable that uses it. did you double check if that really works on both sides? your problem sound to me as if dllimport is missing somewhere. Not enough. I checked this

RE: global_symbol_pipe not picking up an initialized global variable with msvc

I tried to reproduce (but failed, so I think the symbol pipe is definitely out of the loop): I agree. I was on the road to put this together when I found the broken UTL_EXPORT as the culprit. Thanks for going to the trouble to build a simple example. By bad for not doing this before I posted

RE: different flags for static and shared

#if BUILDING_LIBFOO HAVE_VISIBILITY #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__(default))) #elif BUILDING_LIBFOO defined _MSC_VER #define LIBFOO_DLL_EXPORTED __declspec(dllexport) #elif defined _MSC_VER #define LIBFOO_DLL_EXPORTED

global_symbol_pipe not picking up an initialized global variable with msvc

I'm pretty sure I'm running into a pr-msvc-support-specific problem but I'm still learning about libtool so... I'm trying to get rid of unresolved externs when linked an executable against a libtool shared library compiled with msvc. The unresolved externs are global variables. The code in

RE: different flags for static and shared

On July 25, 2009, Ralf Wildenhues wrote: * David Byron wrote on Tue, Jun 30, 2009 at 12:22:52AM CEST: In the case where a build directory is configured for static only (e.g. invoked with --disable-shared) I can add -DLIBFOO_STATIC to one of the CPPFLAGS variables, but if a build

using $bindir when installing using msys

I've run into a situation where libtool isn't installing my DLL where I expect it to. I'm invoking configure with these options: --prefix=/c/foo/install --libdir=/c/foo/install/lib/Debug --bindir=/c/foo/install/bin/Debug but when I run make install, libtool leaves me with: $ ls

RE: using $bindir when installing using msys

I'm curious why libtool doesn't seem to be honoring the --bindir option I passed to configure. A fix is being worked on: http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9363 http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9373 Sorry for the noise. -DB

Re: Problem upgrading Xorg--libtool issue?

Hi Ralf, Thanks for the reply. I tried the dummy lib option and amazingly it worked. As far as I can tell, all the apps I've tried (whether part of xorg or not) seeem to work. David On Fri, 2009-04-10 at 17:50 +0200, Ralf Wildenhues wrote: Hello David, sorry for the delay. * David

Problem upgrading Xorg--libtool issue?

solution. For example, can I simply remove the libxcb-xlib references from all the .la files? How about simply making a dummy libxcb-xlib.so library? Anything else? Thanks in advance. Please CC me directly as I don't subscribe to this list. David

Re: IA64 HP-UX libtool / gcc question about shared libraries

directories not present on the install system. David ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

. -- David Johnson ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: GNU Libtool 2.2 released.

% make make -k check ... All 124 tests passed and 63 tests behaved as expected. 1 test was skipped. (skipped #55: template test with subdirs) Looking forward to using 2.2! Fang David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu

libtool shouldn't automatically link against libc on hppa*-*-hpux*

versions. HP never links shared its libraries against libc. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Index: ltmain.sh

RE: passing flags to the librarian

On Tuesday, December 11, 2007, Duft Markus wrote: You may wanr to have a look at parity (http://www.sf.net/projects/parity). It was written more or less to be more powerfull than cccl (but for now is only tested with interix, not cygwin). I'm going to stick with cccl for now. Also parity

passing flags to the librarian

I'm building a libtool-based package (pcre) using Microsoft command line tools in a cygwin shell. I use a wrapper script for the compiler and linker (cccl), but the librarian (lib) gets invoked directly. I'd like to specify the /LTCG (link time code generation flag) to the librarian. Beats me

Sun Studio linking issues in Solaris 9

= authmysql.lo preauthmysql.lo \ authmysqllib.lo libauthmysql_la_OBJECTS = $(am_libauthmysql_la_OBJECTS) Thanks, -Dave -- David Halik Student Programmer OSS/NBCS - OIT Rutgers [EMAIL PROTECTED

Re: Sun Studio linking issues in Solaris 9

of the Makefile.in and forward your response back to him. I don't see how libtool could be at fault here when the arguments are being given to libtool incorrectly. Thanks for the help anyways, -Dave -- David Halik Student Programmer OSS/NBCS - OIT Rutgers [EMAIL PROTECTED

Re: C++ Plugins and virtual destructors.

. one thrown and uncaught during statics. I'm not sure a C++ plug-in would work in C, but if you had a function for cleaning up resources (something likely to appear in a dtor), you could register a cleanup function with atexit(). Fang David Fang Computer Systems Laboratory Electrical Computer

Re: dlopening installable ltdl modules failing (OS X problem only)

I'm having a problem testing some libtool (ltdl) modules, but only on OS X (darwin7 and darwin8, libtool 1.5.22 and .24). My executable lt_dlopens a .la library in another built directory (during make check testing), and fails with an lt_dlerror message like:

Re: dlopening installable ltdl modules failing (OS X problem only)

It is entirely possible that you've found a bug, Mac OS X should work the same as linux et.al. in this regard. Does the module itself have any dependencies that possibly are not being found (check with otool -L mymodule.0.so)? If that is not the case, please send more info (if you like

Re: dlopening installable ltdl modules failing (OS X problem only)

It is entirely possible that you've found a bug, Mac OS X should work the same as linux et.al. in this regard. Does the module itself have any dependencies that possibly are not being found (check with otool -L mymodule.0.so)? If that is not the case, please send more info (if you

Re: dlopening installable ltdl modules failing (OS X problem only)

Hi, Must've missed this message earlier... The executable takes command-line arguments that call lt_dladdsearchpath (option -L) and lt_dlopenext (option -l). The file, ../../lib/mymodule.la has already been built at the time of testing. The executable is invoked with -L../../lib

dlopening installable ltdl modules failing (OS X problem only)

clear enough. Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ http://lists.gnu.org

Re: libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

build support files are generated with version X, but the above steps can be done to regenerate with version Y. I can see this being applicable to other similar packages that can be shipped as subpackages. David David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell

libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

to pay for? Thanks in advance. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ http://lists.gnu.org

force shared noinst_LTLIBRARIES?

installs (ick). Or is there a simpler (yet still portable) way to do what I want? Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem

Re: force shared noinst_LTLIBRARIES?

On Thu, July 26, 2007 01:20, David Fang wrote: I wasn't able to find an answer for this in the libtool/automake manuals: Is there a way to force libtool (with automake) to create the shared version of an uninstalled library? I would like to use libtool to create local shared

hello-project install failure

-existent path on this host) Hope we can figure this out. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___ Bug

Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

ccache is affecting these results. If you want a verbose log from this set, I can also provide. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem

Re: libtool-1.15.23b (amd64-unknown-freebsd6.2) check results

is terribly wrong... I'm going to investigate further. I can also feel a big slap on my forehead coming... David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) libtool

Re: hello-project install failure

directory!) Many apologies for the noise in the last few days. I will re-run all libtool tests 'properly', and report any *real* problems if I find any. Lesson: don't setenv LD to workaround other's misuse of linkers. Fix their build systems instead. Fang David Fang Computer Systems Laboratory

Re: libtool-1.15.23b (amd64-unknown-freebsd6.2) check results

After unsetenv-ing my LD, the tests look much happier. ... SKIP: demo-nopic.test ... == All 111 tests passed (1 tests were not run) == David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu

Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

After removing LD from my environment: All 112 tests passed David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem

Re: wgcc 2.0 RC1 released

Duft Markus [EMAIL PROTECTED] writes: Hi again! For all interested in native Windows binaries built with Autotools and mnay other interesting things: I'm not sure whether this is on-topic for Boost; it seems of somewhat borderline relevance. However, now that you've started the thread,

Re: [boost] wgcc 2.0 RC1 released

Duft Markus [EMAIL PROTECTED] writes: When building with wgcc there are a few benefits: Wgcc uses the native windows compiler to build (so the code may or may not be faster ;o)) and whats a lot more important: the debug information produced is readable by visual studio, so you can debug the

Re: automake/libtool question

Thank you for responding Ralf, On 9/12/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: [ Cc:ing both lists; let's drop the automake list ] Hello David, * David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST: HP-UX B.11.23 U ia64 automake (GNU automake) 1.9.6 autoconf (GNU Autoconf

linking to non-libtool shared libraries

Sorry, I think I sent this to the wrong list earlier: -- Forwarded message -- From: David Everly [EMAIL PROTECTED] Date: Sep 11, 2006 3:07 PM Subject: automake/libtool question To: automake@gnu.org I'm on the following: HP-UX B.11.23 U ia64 automake (GNU automake) 1.9.6

aCC link options

I would like to suggest the use of +k (-Wl,+k) for linking. Without this, under certain ld failures, the executable is created anyway (but without execute permissions). This means that the next time make runs, the file is present and up to date and so make thinks it can continue. HP-UX B.11.23

Re: handling of missing AR

(if they choose) address some of the warnings that those try defaults generated. Might that model, that frame of mind, help in this libtool cases of things like AR, and the various not-necessarily-be-used compilers? -- : David LeeI.T. Service : : Senior

Libtool(?) frustrations

: lib_libexec_LTLIBRARIES = librivet.la librivetparser.la What might be the cause of this problem? Is there a better place to ask? Thanks for your help, -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com

ltdl dlpreopen behavior

kind of ugly... Any suggestions? I imagine my program would be a fairly common design wrt builtin+optional modules (the linux kernel is an obvious example). Thanks, David ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, David Lee wrote: [...] For instance, do we _know_ that this S10/[EMAIL PROTECTED] problem is _definitely_ 100% attributable to GNU/ld? Is libtool known/proven to be not contributing in any way to this problem? As was mentioned in my email of 29th June, the make check

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: (Incidentally: this may or may not be relevant to the above: in my own case, I know that our GNU ld and libtool are somewhat out-of-date. So I've attempted to get libtool 1.5.18 installed

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, Howard Chu wrote: Bob Friesenhahn wrote: On Mon, 4 Jul 2005, David Lee wrote: I'm using GNU/ld; but I'd be happy,as part of the experiments, to try to redirect our gcc to use the Solaris/ld. (How to redirect it?) I recommend that anyone who installs GCC under Solaris

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: Quite a few folk seem to be having trouble linking on Solaris 10. These seem to be well-established applications, that have compiled and linked for years on a wide range of OSes, including

Re: [patch] list of input files if max_cmd_len exceeded

appending. David

Re: [patch] list of input files if max_cmd_len exceeded

, using loop and initializing $output file. Thanks, David * config/ltmain.m4sh (func_mode_link): If command exceeds max_cmd_len and file_list_spec exists, write list of input files to temporary file. * m4/libtool.m4 (_LT_LINKER_SHLIBS, aix[45]): Define file_list_spec

[patch] list of input files if max_cmd_len exceeded

in GCC. Thanks, David * config/ltmain.m4sh (func_mode_link): If command exceeds max_cmd_len and file_list_spec exists, write list of input files to temporary file. * m4/libtool.m4 (_LT_LINKER_SHLIBS, aix[45]): Define file_list_spec. (_LT_LANG_CXX_CONFIG, aix

Re: [patch] list of input files if max_cmd_len exceeded

of the existing linker script support? Peter can't you just do this? Peter output=$file_list_spec$filelist I will investigate that further. Thanks, David

RE: Building JNI libraries on MacOS X and other systems

. To use it for jnilibs, you will have to have some configury to set the option on MacOS X only. HTH, Robert -- . David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED]5515

Lower your payments

___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Linking problem

the documentation for my computer architecture I found out that all the files in both of the sets are PIC. So there shouldn't be any difference between them. But when I link the library using the files in . directory - every thing is ok. Do you happen to know, where the problem is? David P.S.: I have

Re: hppa*64* and dependent libraries

. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2002-07-09 John David Anglin [EMAIL PROTECTED] * libtool.m4 (hpux10.20*|hpux11*): Add lt_cv_deplibs_check_method

Re: hppa*64* and dependent libraries

linked with libstdc++.sl no longer worked. I removed the dot dots from the dependencies a few months ago. The downside in doing this is that it is now no longer possible to move the gcc tool directory by inserting a symbolic link. Dave -- J. David Anglin [EMAIL

Re: hppa*64* and dependent libraries

original libtool patch for binutils. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org

Re: hppa*64* and dependent libraries

and append the specified path to the accumulated rpath. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

, this define for LD isn't a proper default. So, I am wondering if the libtool script should also reset LD when LD=ld? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605

  1   2   >