Problem : strange warning

is located at /usr/local/bin on my system. I don't see where the problem can be... It would be great if you could help me with this ! Best regards, Pierre. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Problem with libtool

is located at /usr/local/bin on my system. I don't see where the problem can be... It would be great if you could help me with this ! Best regards, Pierre. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Enabling/disabling shared or static libs from Makefile.am

? I would not mind if all source files were compiled as position-independent code, even for static libraries. -- Pierre Sarrazin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Job offer

Hi, Do you want to earn some extra $$$ working from home? We have a great offer for you! Our corporation Ship & Pay Intl. is constantly looking for trustworthy people to be our representatives in your country! You'll need NO money and NO special skills to start working. Anyone can work with us,

lt_dlopen with modules and no .la

oblem should be the same on all systems, so I'm guessing this is intended behaviour. So I'm wondering what's the rationale? -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com

Re: lt_dlopen with modules and no .la

Ralf Wildenhues wrote: Hi Bob, Pierre, * Bob Friesenhahn wrote on Wed, Dec 21, 2005 at 08:47:27PM CET: On Wed, 21 Dec 2005, Pierre Ossman wrote: When using ltdl on Windows to load plug-ins there is a problem with the name mangling system. The info.name field is only set if libltdl finds a

Re: lt_dlopen with modules and no .la

Ralf Wildenhues wrote: Hi Pierre, * Pierre Ossman wrote on Thu, Dec 22, 2005 at 09:26:02AM CET: On Wed, 21 Dec 2005, Pierre Ossman wrote: When using ltdl on Windows to load plug-ins there is a problem with the name mangling system. The info.name field is only set if libltdl finds a .la

Re: lt_dlopen with modules and no .la

'm using 1.5.20 here. That was the newest version when we did the upgrade a couple of weeks ago. I'm trying to be a user, not a developer so running a CVS version wasn't really planned. ;) -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio AB

Preloading without .la

oblems. * Use the dynamic prefix for the name embedded in the preload module. I.e. do a 'sed s/$(STATIC_EXT)\$/$(SHLIB_EXT)/' on the name as it is being embedded. Not sure what the obstacles are here. Perhaps some problem with breaking existing hacks. Comments welcome

Re: Preloading without .la

Pierre Ossman wrote: * Use the dynamic prefix for the name embedded in the preload module. I.e. do a 'sed s/$(STATIC_EXT)\$/$(SHLIB_EXT)/' on the name as it is being embedded. Not sure what the obstacles are here. Perhaps some problem with breaking existing hacks. And thi

Re: lt_dlopen with modules and no .la

Pierre Ossman wrote: Bob Friesenhahn wrote: What happens if the path specified by 'base_name' does not include a '.'? Does it crash? Good point. It should be surrounded by an 'if (ext)'. Note that the code in development libtool is quite different than the

Re: Preloading without .la

Pierre Ossman wrote: Pierre Ossman wrote: * Use the dynamic prefix for the name embedded in the preload module. I.e. do a 'sed s/$(STATIC_EXT)\$/$(SHLIB_EXT)/' on the name as it is being embedded. Not sure what the obstacles are here. Perhaps some problem with breakin

Re: Preloading without .la

Ralf Wildenhues wrote: Hi Pierre, Hi Ralf, * Pierre Ossman wrote on Tue, Jan 03, 2006 at 05:36:05PM CET: I've been trying to use ltdl preloading without having any .la files, something that doesn't currently seem to be supported. I'm willing to implement a fix, provid

Re: Preloading without .la

'lib' will not work. The reason is that the above magic cannot tell the difference between 'libfoo' and 'foo' (which will be transformed to 'libfoo') on such a system. Please review and comment. If it looks good I'll make a patch for HEAD and

RPATH on x86_64?

rd to read. So I was hoping someone could explain in plain English how it's supposed to work. :) Rgds -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: RPATH on x86_64?

also some environment variable that can be used to pass this information? That would allow "make RPATHENV=/usr/lib64" and I wouldn't have to mess with the build system. Thanks -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: h

Re: Preloading without .la

Ralf Wildenhues wrote: [ Let's move this to libtool-patches Note also the list server may not come back up for a few days. ] Major breakage? Hi Pierre, Sorry for the delay. No problem. * Pierre Ossman wrote on Fri, Jan 27, 2006 at 05:30:22PM CET: I've put together a

Re: RPATH on x86_64?

Ralf Wildenhues wrote: * Pierre Ossman wrote on Wed, Mar 01, 2006 at 10:00:43AM CET: Is there perhaps also some environment variable that can be used to pass this information? That would allow "make RPATHENV=/usr/lib64" and I wouldn't have to mess with the build system. No

Avoiding to install some static libs

iguring out how to get automake to give libtool the --tag probably) but not a way to disable installing them, then that is possible solution, although not preferable. -- Rgds Pierre OssmanTelephone: +46-13-21 46 00 Cendio AB

Re: Avoiding to install some static libs

add -rpath $libdir manually to *LDFLAGS, additionally to -module. Hope that helps. Hmm... Not as clean as I had hoped. I think we'll keep them for now and people will have to accept the clutter (or packagers clean it up). Thanks anyway. -- Pierre OssmanTelephone: +46-13-21

Re: Preloading without .la

I guess this issue got lost somewhere. As the issue persists for me and I'd rather not use a homebrew build environment, I'd still like this to be resolved. Rgds Pierre Pierre Ossman wrote: > Ralf Wildenhues wrote: >> [ Let's move this to libtool-patches >> Not

Re: Preloading without .la

Another reminder... Pierre Ossman wrote: > I guess this issue got lost somewhere. As the issue persists for me and > I'd rather not use a homebrew build environment, I'd still like this to > be resolved. > > Rgds > Pierre > > Pierre Ossman wrote: >> Ralf

Re: Preloading without .la

I upgraded to libtool 2 the other day and was hit by this bug again. Has there been any work on fixing this rather large hole in the preload functionality? On Tue, 22 Aug 2006 16:20:01 +0200 Pierre Ossman wrote: > Another reminder... > > Pierre Ossman wrote: > > I guess this

Re: Preloading without .la

On Wed, 2 Dec 2009 17:44:49 +0100 Pierre Ossman wrote: > I upgraded to libtool 2 the other day and was hit by this bug again. > Has there been any work on fixing this rather large hole in the preload > functionality? > It seems things are different these days. The problem is now s

Re: Preloading without .la

On Wed, 2 Dec 2009 12:58:47 -0600 (CST) Bob Friesenhahn wrote: > On Wed, 2 Dec 2009, Pierre Ossman wrote: > > > I upgraded to libtool 2 the other day and was hit by this bug again. > > Has there been any work on fixing this rather large hole in the preload > > functio

Re: Preloading without .la

On Wed, 2 Dec 2009 18:34:06 +0100 Pierre Ossman wrote: > > So either libtool needs to start mangling, or libltdl needs to stop. > I'm voting for the former as symbol names can already contain the > mangled module name. > Apparently this wasn't a good idea. Some appl

Re: Preloading without .la

he preload table to be unmangled so we need to change libltdl to stop doing that. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com From 5f136168282724689f8da99d45fd0324e8

Make deplibs check fallback work for 64-bit Windows and Windows CE

The "normal" check was fixed some time ago, but the fallback code was overlooked. This patch fixes that as well. Btw, why isn't the original fix (b5282894) in the 2.2.6b release? The fix is over one year old and still isn't in any released version. Rgds -- Pierre Ossman

libtool 1.4.3 searches /usr/lib before -L

ask libtool to search a certain directory before any system directory? My project is autoconfiscated with autoconf 2.57, automake 1.7.2 and libtool 1.4.3. Also, I use g++ 3.2 on a RedHat 8.0 system. -- Pierre Sarrazin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.3 searches /usr/lib before -L

//'`" $newlib_search_path" else compile_deplibs="$deplib $compile_deplibs" finalize_deplibs="$deplib $finalize_deplibs" fi ;; This puts the right directory before /usr/lib instead of after. (I notice that this code segment is the only one in t

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

: None ___ Follow-up Comments: --- Date: Tue 04 Feb 2025 10:42:32 AM UTC By: Pierre Ossman We want to link libstdc++ statically to avoid dependency problems on deployed systems. To do this,

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

Follow-up Comment #1, sr #84 (group libtool): It breaks even further with dynamic libraries, where libtool insists on adding -nostdlib. It was discussed in a different libtool bug tracker here, without any resolution: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34219 _

[sr #111214] libltdl gives up too early on multi-arch systems

: None ___ Follow-up Comments: --- Date: Tue 01 Apr 2025 01:47:44 PM UTC By: Pierre Ossman When we ask libltdl to open a module for us, it gives up when it finds a matching file that dlopen() fails to open. T

[sr #111213] libtool reorders --as-needed, breaking it

: None ___ Follow-up Comments: --- Date: Tue 01 Apr 2025 01:44:51 PM UTC By: Pierre Ossman We want to add --as-needed to some of our libraries to avoid dragging in unneeded dependencies in some complex build s

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

Follow-up Comment #4, sr #84 (group libtool): Thanks! It does indeed seem like the patch and configure flag resolves the issue! ___ Reply to this item at: _