Re: Problem with libtool adding -pthread

On Sun, Nov 28, 2010 at 12:39 PM, John R. Cary wrote: > On 11/28/10 10:25 AM, Ralf Wildenhues wrote: >> >> Hello John, >> >> * John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET: >>> >>> I am tring to link with libtool using the compiler >>> wrappers on a Cray and with pgi. >>> >>> At final

Re: Problem with libtool adding -pthread

On 11/28/10 10:25 AM, Ralf Wildenhues wrote: Hello John, * John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET: I am tring to link with libtool using the compiler wrappers on a Cray and with pgi. At final link, libtool inserts the flag, -pthread, which causes the compiler to fail. This

Re: Problem with libtool adding -pthread

Hello John, * John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET: > I am tring to link with libtool using the compiler > wrappers on a Cray and with pgi. > > At final link, libtool inserts the flag, -pthread, which > causes the compiler to fail. This is shown below. Uh, that's probably b

Re: Problem with libtool adding -pthread

System information below On 11/28/10 7:02 AM, John R. Cary wrote: I am trying to link with libtool using the compiler wrappers on a Cray and with pgi. At final link, libtool inserts the flag, -pthread, which causes the compiler to fail. This is shown below. Is there some way around this? Also

Problem with libtool adding -pthread

I am tring to link with libtool using the compiler wrappers on a Cray and with pgi. At final link, libtool inserts the flag, -pthread, which causes the compiler to fail. This is shown below. Is there some way around this? Also, while the original link line contains -L/opt/fftw/3.2.2/lib -lfft

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

* Rafał Mużyło wrote on Wed, Jul 29, 2009 at 09:15:27PM CEST: > On Wed, Jul 29, 2009 at 07:22:54PM +0200, Ralf Wildenhues wrote: > > > > Libtool 2.2.6 allows you to specify global or local visibility with the > > lt_dladvise_local and lt_dladvise_global functions. > > > Just to make sure: that was

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

On Wed, Jul 29, 2009 at 07:22:54PM +0200, Ralf Wildenhues wrote: > > unixODBC bundles libtool, as it patches it. It does that, > > cause LT_GLOBAL in dlopen call causes a problem when > > unixODBC is used by Perl::ODBC module. > > Libtool 2.2.6 allows you to specify global or local visibility with

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

Hello Rafał, thanks for the report. * Rafał Mużyło wrote on Wed, Jul 29, 2009 at 02:06:48PM CEST: > Following problem is of only limited interest for me, > but I think some input from libtool people could be useful there. FWIW, this is . > unixODBC bundles libtool

Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

Following problem is of only limited interest for me, but I think some input from libtool people could be useful there. unixODBC bundles libtool, as it patches it. It does that, cause LT_GLOBAL in dlopen call causes a problem when unixODBC is used by Perl::ODBC module. Now, my question is: is thi

Re: problem with libtool under windows and cygwin

Andreas Otto wrote: > > as special restriction I use the build-tools from cygwin > but it is no cygwin library at all because I use the > build-in mingw compiler > > gcc -mno-cygwin This is *not* a "built-in mingw compiler. It's a hack that sometimes works, but always causes proble

problem with libtool under windows and cygwin

Hello, just an other question for my software porting project I'm using libtool to create libraries on unix and windows on both system it works fine. later I use this library in java code as JNI library with: System.loadLibrary("javamsgque"); this works fine on UNIX be

Re: Dynamic libraries linking problem with Libtool

I catched the bug this morning, I just forgot to change the ".la" name in the dlopen() call that I set while I was experimenting compilation values :D > Don't get insane by working 10 hours without progress. Ask after a > couple of hours. ;-) Thank you for your suggestions! Best wishes Roberto

Re: Dynamic libraries linking problem with Libtool

Hello Roberto, * Roberto Rigamonti wrote on Thu, Mar 06, 2008 at 04:23:31PM CET: > Hi, I've already posted a related question on > http://www.linuxquestions.org/ today, but it seems that nobody there is > Libtool-expert so I've decided to crosspost here. > I've put a detailed explanation of my pro

Dynamic libraries linking problem with Libtool

Hi, I've already posted a related question on http://www.linuxquestions.org/ today, but it seems that nobody there is Libtool-expert so I've decided to crosspost here. I've put a detailed explanation of my problem here: http://www.linuxquestions.org/questions/programming-9/c-dynamically-loaded-libr

Re: problem with libtool generated version script and underscores

libtool automatically discovers the prefix in _LT_CMD_GLOBAL_SYMBOLS and stores the result into ac_symprfx (in libtool.m4). i think all we need to do is have _LT_LINKER_SHLIBS declare an m4_require on _LT_CMD_GLOBAL_SYMBOLS and then we can use ac_symprfx in archive_expsym_cmds by adding an expr

Re: problem with libtool generated version script and underscores

Hi all, Are there any comments on my patch? Is there anything wrong with it? Regards, Aleksey ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: problem with libtool generated version script and underscores

On Thu, Feb 14, 2008 at 5:49 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > >>Can we see testsuite output for Libtool 2.1b (see README) for a system > >>that needs a change here? This failure should be exposed already. Esp. > >>the stresstest should expose most use cases here. > > I disagre

Re: problem with libtool generated version script and underscores

* Aleksey Demakov wrote on Thu, Feb 14, 2008 at 12:46:25PM CET: > On Thu, Feb 7, 2008 at 2:23 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > Please take a look at AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE in libtool.m4. > > [...] > > > > > That is while finding the correct global_symbol_pipe command

Re: problem with libtool generated version script and underscores

On Thu, Feb 7, 2008 at 2:23 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > Please take a look at AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE in libtool.m4. > [...] > > > That is while finding the correct global_symbol_pipe command it uses > > temporary variable $ac_symprfx. I think this variable could

Re: problem with libtool generated version script and underscores

* Aleksey Demakov wrote on Wed, Feb 06, 2008 at 08:01:42PM CET: > On Feb 6, 2008 11:51 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > Blackfin is not the only target that utilizes underscore prefixes. a more > > generic check (as noted in the previous thread you cited) would be to > > consi

Re: problem with libtool generated version script and underscores

On Feb 6, 2008 11:51 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > Blackfin is not the only target that utilizes underscore prefixes. a more > generic check (as noted in the previous thread you cited) would be to > consider the define from gcc __USER_LABEL_PREFIX__. > -mike > Please take a lo

Re: problem with libtool generated version script and underscores

Mike Frysinger wrote: > On Wednesday 06 February 2008, Peter O'Gorman wrote: >> Mike Frysinger wrote: >>> Blackfin is not the only target that utilizes underscore prefixes. a >>> more generic check (as noted in the previous thread you cited) would be >>> to consider the define from gcc __USER_LABE

Re: problem with libtool generated version script and underscores

On Wednesday 06 February 2008, Peter O'Gorman wrote: > Mike Frysinger wrote: > > Blackfin is not the only target that utilizes underscore prefixes. a > > more generic check (as noted in the previous thread you cited) would be > > to consider the define from gcc __USER_LABEL_PREFIX__. > > Feel free

Re: problem with libtool generated version script and underscores

Mike Frysinger wrote: > > Blackfin is not the only target that utilizes underscore prefixes. a more > generic check (as noted in the previous thread you cited) would be to > consider the define from gcc __USER_LABEL_PREFIX__. > -mike Hi Mike, Feel free to send patches. Peter -- Peter O'Gorm

Re: problem with libtool generated version script and underscores

On Wednesday 06 February 2008, Aleksey Demakov wrote: > On Feb 6, 2008 9:18 PM, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > What is the host triplet for the system that you are building for? > > Umm the canonical host name must be something like > bfin-unknown-linux. > > > You need to set archive

Re: problem with libtool generated version script and underscores

On Feb 6, 2008 9:18 PM, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > What is the host triplet for the system that you are building for? > Umm the canonical host name must be something like bfin-unknown-linux. > You need to set archive_expsym_cmds for that system to be similar to > interix[[3-9]]*

Re: problem with libtool generated version script and underscores

Aleksey Demakov wrote: > On Feb 6, 2008 2:51 AM, Aleksey Demakov <[EMAIL PROTECTED]> wrote: >> I try to build a library (glib to be specific) with a cross-toolchain >> that prepends underscore to C names. The problem is that the >> symbols the library has to export do not get exported. >> > > By t

Re: problem with libtool generated version script and underscores

On Feb 6, 2008 2:51 AM, Aleksey Demakov <[EMAIL PROTECTED]> wrote: > I try to build a library (glib to be specific) with a cross-toolchain > that prepends underscore to C names. The problem is that the > symbols the library has to export do not get exported. > By the way my problem looks just the

problem with libtool generated version script and underscores

Hi all, I try to build a library (glib to be specific) with a cross-toolchain that prepends underscore to C names. The problem is that the symbols the library has to export do not get exported. The command used to build the library is provided by the end of the message. Please note the option "-e

Re: Problem with libtool

Hello Richard, * Richard Graham wrote on Thu, Jan 10, 2008 at 10:14:46PM CET: > I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran > into the following problem. In our configure script we get the wl parameter > set to -Wl, > > But when the following part of the build is ru

Problem with libtool

I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran into the following problem. In our configure script we get the wl parameter set to -Wl, But when the following part of the build is run: /bin/sh ../../../libtool --tag=CC --mode=link cc -O2 -I/opt/xt-pe/default/include/

Re: problem with libtool 1.9f on AIX linking f95...

Hi Ed, * Ed Hartnett wrote on Wed, Jan 04, 2006 at 04:56:03AM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > Surely LTFCLINK should contain --tag=FC, too. This needs to be fixed in > > Automake. > > Sorry, you've lost me here... Don't worry. Eventually, we'll hash this out with Alex

Re: problem with libtool 1.9f on AIX linking f95...

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Now that you've moved to CVS libtool anyway: shouldn't you be able to > remove the --tag=F77 cruft, and use LT_LANG(Fortran) and > configure FC=xlf90 Howdy Ralf! > > and everything should work fine? > (Except for the FCFLAGS_$SRCEXT which you'll st

Re: problem with libtool 1.9f on AIX linking f95...

Hi Ed, * Ed Hartnett wrote on Sat, Dec 24, 2005 at 04:45:21PM CET: > > On an AIX platform, I am seeing the following error: > > Target "check" is up to date. > Making check in f90 > /bin/sh ../libtool --tag=F77--mode=compile xlf90 -I../libsrc4 -I. > -I/home/ed/local/zasu/include -g -

problem with libtool 1.9f on AIX linking f95...

Howdy all! On an AIX platform, I am seeing the following error: Target "check" is up to date. Making check in f90 /bin/sh ../libtool --tag=F77--mode=compile xlf90 -I../libsrc4 -I. -I/home/ed/local/zasu/include -g -qsuffix=f=f90 -c -o typeSizes.lo typeSizes.f90 xlf90 -I../libsrc4 -I

Re: Fw: Problem with libtool under HPUX: BIND_FIRST flag is required

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | | Hrmpf. I did not find this during my earlier search. | | I don't know really what to do. I'm reluctant to change branch-1-5 in | this respect. It's supposed to be a stable series, after all. :-/ I'd rather not see this

Re: Fw: Problem with libtool under HPUX: BIND_FIRST flag is required

* Ralf Wildenhues wrote on Thu, Dec 01, 2005 at 02:17:25PM CET: > * Jan Giesen wrote on Wed, Nov 30, 2005 at 10:48:10PM CET: > > You wrote: > > > We need RTLD_GLOBAL by default at the moment, simply because some > > > libltdl users expect things to work this way. Gah. Please forget all of this, i

Re: Fw: Problem with libtool under HPUX: BIND_FIRST flag is required

Hi Jan, * Jan Giesen wrote on Wed, Nov 30, 2005 at 10:48:10PM CET: > You wrote: > > We need RTLD_GLOBAL by default at the moment, simply because some > > libltdl users expect things to work this way. *snip* > Thank you for the information; I understand now better how Libtool works. > For me this

Fw: Problem with libtool under HPUX: BIND_FIRST flag is required

Dear Ralf, You wrote: > We need RTLD_GLOBAL by default at the moment, simply because some > libltdl users expect things to work this way. We could add a new > interface which allows some kind of localization of symbol scope, > say lt_dlopen_mode("foo.la", LT_DL_LOCAL), but what about graceful > de

Re: Problem with libtool under HPUX: BIND_FIRST flag is required

Hi Jan, * Jan Giesen wrote on Sun, Nov 27, 2005 at 10:56:26PM CET: > > The trigger libraries are itself loaded explicitly with lt_dlopen(), but not > in the main programm, but in a another shared library, which is implicit > loaded from the main program. > To access a trigger library a pointer to

Re: Problem with libtool under HPUX: BIND_FIRST flag is required

Dear Ralf You wrote: > Hi Jan, > > * Jan Giesen wrote on Fri, Nov 25, 2005 at 11:16:26PM CET: > > I have encountered a libtool problem, when I tried to build > > cvsnt 2.5.03.2151 (cf. www.cvsnt.org) under HPUX 11.11. > > This problem could be reproduced with libtool version 1.5.6 > > as well as w

Re: Problem with libtool under HPUX: BIND_FIRST flag is required

Hi Jan, * Jan Giesen wrote on Fri, Nov 25, 2005 at 11:16:26PM CET: > I have encountered a libtool problem, when I tried to build > cvsnt 2.5.03.2151 (cf. www.cvsnt.org) under HPUX 11.11. > This problem could be reproduced with libtool version 1.5.6 > as well as with 1.5.20: Hrmpf, I need to fill

Problem with libtool under HPUX: BIND_FIRST flag is required

I have encountered a libtool problem, when I tried to build cvsnt 2.5.03.2151 (cf. www.cvsnt.org) under HPUX 11.11. This problem could be reproduced with libtool version 1.5.6 as well as with 1.5.20: Subroutines in shared libraries, which are loaded at runtime using libtldl are not correctly linked

Re: problem with libtool on Darwin

Sorry for this spamming, I was terminally confused. I have a large library in FORTRAN and I am trying to put it under auto-tools, being a newbie. Things seem to be going more or less ok now. I have still a problem with CONFIG_HEADERS in Fortran, because of the c-style comments, so I am defi

Re: problem with libtool on Darwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Federico Carminati wrote: | Hello, | may be I am completely wrong... however. If I use service libraries | in subdirectories to create a main library with Fortrran on Darwin I | have a problem. libtool correctly compiles the objects for the share

problem with libtool on Darwin

Hello, may be I am completely wrong... however. If I use service libraries in subdirectories to create a main library with Fortrran on Darwin I have a problem. libtool correctly compiles the objects for the shared libs in the subdirs with -fno-common and creates shared service libraries.

Link problem with libtool on AIX with OpenMP

Hi, I'm using xlc_r to compile a backend library and multiple front-end executables to the library under AIX 5.1. The library, and _some_ of the front end executables (i.e., some of the main() functions) contains SMP/OpenMP code so I make sure to compile and link with -qsmp=omp. All of this, by the

maybe a problem with libtool-1.5

Hello, Don't really know if it's a problem with libtool-1.5 but I know that I already built php4.3.3 with libtool-1.4.2. I tried to build php4.3.3 with the following config: $ ../configure --prefix=/opt --srcdir=.. --host=x86-pc-nto-qnx --without-pear --with-zlib=/opt --with-iconv=/op

Problem with libtool

Hi, When trying to build some apps, I got this : [...] checking dynamic linker characteristics... Linux ld.so checking if libtool supports shared libraries... yes *** Warning: the command libtool uses to detect shared libraries, *** /usr/bin/file, produces output that libtool cannot recognize. *

Problem with libtool + Microsoft CL & LINK

I'm having trouble getting a small package I wrote to build on Win32 with Microsoft's compiler and linker (using Cygwin for the Unix toolchain side of things). Here are the relevant lines from my Makefile.am: lib_LTLIBRARIES = libsimpprof.la libsimpprof_la_SOURCES = simpprof.c simpprof

Re: prelink problem with libtool 1.4.2 on Irix 6.5

Support for this feature is not present in the libtool 1.4 stable branch. C++ libraries are in fact barley supported at all prior to libtool-1.4b (1.4a is a random snapshot from the CVS trunk somewhere between 1.4 and 1.4b, and is not even alpha quality). The libtool web pages talk about the vers

prelink problem with libtool 1.4.2 on Irix 6.5

Hello, we were using libtool 1.4a on Irix 6.5, with automake 1.5 and autoconf 2.52. We create some shared C++ libraries that require automatic template instantiation. Mips CC does this by doing a pre-link stage before creating the shared library. This was correctly happening with libtool 1.4a.

Compiler problem with libtool on CVS ML branch

Hello. I have been trying to figure out why libtool tries to detect and use both gcc and cc. If anyone could provide some insight that would be great. Here is the output I am seeing while running ./configure ./configure ... checking for gcc... gcc checking whether the C compiler works... yes ch