Re: Issue with added '-threads' added while using Intel 2024.0.0 C compiler icx

system. PS. Please let me know if it is ill posed problem at all or if you don't discuss issues involving non-GNU compilers at all. Libtool should work with non-GNU compilers. Hope that helps, Nick Regards, Roumen Petrov

Re: libtool is adding "-L/usr/lib" even for cross-compilation with sysroot

Hi, Xi Ruoyao wrote: Hi libtool dev, We've recently hit an issue cross-compiling some package using libtool for sysroot. Saying libfoo.la contains So there is a number of models . One to use system libtool and another one libtool script builds for project. First is not for cross-compilation.

Re: New libtool maintainer

/debbugs.gnu.org/cgi/bugreport.cgi?bug=53479 If those bugs are not Debian specific someone could look at them. Libtool projects must not care for defects that shows Debian libtool brokenness. Regards, Roumen Petrov

Re: new release?

ased 2.6. It seems to me more users will test release version then beta or release candidate. [SNIP] Regards, Roumen Petrov

Re: disable invocation of winepath by libtool

emulated environment on Linux. I cannot understand why wine in installed but not properly setup. Either remove wine or finish installation. Regards Roumen Petrov

Re: lt_dlopen an uninstalled library

Hi ilya, ilya Basin wrote: Hi List. I'm making a program with plugins as shared libraries and when I run `make check` I want my program to load the uninstalled plugins using lt_dlopen(). I expected that passing `-dlopen libname.la` to libtool would force the generation of a wrapper script set

Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project

clspec(dllimport) # endif in the last #else, I don't know what to do to correctly manage MY_API for my problem above One solution would be : never compile 'lbfoo' as a static lib ("DLL are good on Windows"), but I would like to support both static and shared libraries. Does someone know how to solve my issue ? (I hope I've been clear enough...) thank you Vincent Torri Regards, Roumen Petrov

Re: transitive shared library dependencies and installation

Hi Russ, libtool members, I work on open source projects in my spare time. And so I can not provide feedback promptly. Today I have time to re read mail thread and to clarify my strong position. Russ Allbery wrote: Roumen Petrov writes: Urgh, article with very limited niche. First is

Re: transitive shared library dependencies and installation

seems to me question is how to remove some extra dependencies : automatically (--as-needed) or manually (using tools like patchelf). May be topic is not for libtool list. Regards, Roumen Petrov

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

Martin Liška wrote: [SNIP] However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output. Thank you for identification of the root cause. I've just created a nm issue for that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355 It is clear th

Re: transitive shared library dependencies and installation

  Library rpath: [/tmp/translib/lib] Regards, Roumen Petrov

Re: transitive shared library dependencies and installation

Hello, wf...@niif.hu wrote: Roumen Petrov writes: wf...@niif.hu wrote: I'm experimenting with the attached skeleton project on a Debian buster Debian is key word. system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9): Libtool is patched, not FSF. [SNIP] /usr/b

Re: transitive shared library dependencies and installation

t;delayed" until the relinking phase? Not reproducible with FSF release. Regards, Roumen Petrov

Re: [sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

xecutable from regression tests should use library from "build tree" not system one. Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

uri wrote: > On 2019-06-24 09:55, Roumen Petrov wrote: >> >> And projects builds just fine! >> Conclusion - there is no defect neither in libtool nor in automake nor >> in project autotool files. >> >> Reporter still does not provide feedback with informatio

Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

Dunno what is wrong in Yuri's FreeBSD environment Bob Friesenhahn wrote: On Sun, 23 Jun 2019, Yuri wrote: So is there an easy way to override this and always use C++ way of linking? To do this you might need to set LD or CC to your C++ compiler.  A better way is to make your main program b

Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

Yuri wrote: On 2019-06-23 12:19, Roumen Petrov wrote: cc ? I'm not sure which compiler suite is used on FreeBSD but it seems to me C++ compiler is not installed. clang8 is used. cc is a C compiler, c++ is a C++ compiler. Ok. Dunno why is not detected c++ at configure time. I&

Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

Yuri wrote: On FreeBSD libtool can't find operator new[] because it is in C mode: libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize -pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o RNALfold

Re: Accounting for -rpath when libtool isn't helping

ist to avoid -rpath flag. For some autoconf builds with use of libtool you could force -rpath if needed - add those options to LDFLAGS ( see ./configure --help) . Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: Why is Guile unable to find libtool?

btool" script(s) will be generated in build tree. Regards, Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: Does libtool need to escape plus signs in egrep expressions?

rt in regular expressions but according above tests "plus" in RE works - see case _head__al . Note that the function that does this is only used in rather exotic corner-cases (old dlltool and/or ms dumpbin being in use), so it's plausible that it could have been broken since

Re: libtool problem

Hello Alice, Alice Wonder wrote: Hello, [SNIP] Software (audacity) [SNIP] libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' [SNIP] LIBTOOL=/opt/gnu/bin/libtool libtool is generated script . Generated script has variable available_tags= and

Re: merging various libraries into a single DLL on windows

Werner LEMBERG wrote: Folks, my ttfautohint library exports a single function (`TTF_autohint') and depends on freetype and harfbuzz. A user posted the following recipe to merge these three libraries into a single DLL in Windows. Looks like use of libtool "Convenience" libraries. [SNIP] Reg

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

You could use lt_cv_sys_lib_dlsearch_path_spec to override it at configure time. .../configure \ ... lt_cv_sys_lib_dlsearch_path_spec=" " ... Regards Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool automake android pthread

Hi, Gerry Reno wrote: On 04/03/2012 03:20 PM, Bob Friesenhahn wrote: On Tue, 3 Apr 2012, Gerry Reno wrote: Hi Bob. I think it's more of an issue that Android does not need an external pthread library. These projects all compiled and linked fine on Linux. But when you try to link them usin

Re: Bad LD_LIBRARY_PATH set in the libtool wrapper

Sam Varshavchik wrote: My source tree builds two libraries, from two separate directories in the source tree. libxtls.la gets linked against libx.la in a different directory, as well as some system libraries in /usr/local/lib. Makefile.am declares thusly: libxtls_la_LIBADD=../base/libx.la l

Re: bootstrap --copy

Hello Gary, [SNIP] Usage: bootstrap MACRO_NAME FILE [...] Try `bootstrap --help' for more information. bootstrap: error: unrecognised option: `--copy' G'ah! Sorry about that. I'm pushing a fix now. Now --copy may is fine but script fail: Usage: bootstrap MACRO_NAME FILE [...] Try

bootstrap --copy

Hello Gary, After monster updates in repository please could you help me to bootstrap libtool. I don't like to create symbolic links, so I use --copy argument , but since 2011-11-08 it does not work. The command is ./bootstrap \ --copy \ --force \ --gnulib-srcdir= Outpu

Re: Obsoleting LT_SCOPE

Hi Gary, Gary V. Vaughan wrote: Hi Chuck, I note that no other GNU projects that I'm aware of jump through all the __declspec hoops that the libltdl API tries to provide through LT_SCOPE. Is any of this stuff still required on any non-museum Windows compiler that would break if I removed it? []

Re: libtool, multilib and test "duplicate convenience archive names"

Hi Andreas and Bo, Please could you clarify build of 64-bit system for 32 bit. Roumen Petrov wrote: Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to '

libtool, multilib and test "duplicate convenience archive names"

Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to 'gcc|g++ -m32', i.e. multilib . The libtool regression suite fail in test case : 25: duplicate convenience arch

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

Gary V. Vaughan wrote: Hi Roumen, On 22 May 2010, at 03:26, Roumen Petrov wrote: Gary V. Vaughan wrote: The Libtool Team is pleased to announce release candidate 2.2.7b of GNU Libtool. If there are no serious deficiencies reported in this release, it will be renumbered as 2.2.8 and re

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

Gary V. Vaughan wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. The Libtool Team is pl

Re: Extend libtool dll namespaces for mingw-w64

JonY wrote: On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_

Re: Extend libtool dll namespaces for mingw-w64

I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requeste

Re: Extend libtool dll namespaces for mingw-w64

Matěj Týč wrote: [SNIP] Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silence complaints. [SNIP] -module flag will install dll in $libdir and without

Re: Extend libtool dll namespaces for mingw-w64

Matěj Týč wrote: On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: ... I suggest the following naming scheme. mingw.org: lib-.dll (unchanged) Cygwin: cyg-.dll (unchanged) mingw-w64(64): lib64-.dll mingw-w64(32): lib32-.dll libtool should also check if GCC "-m32" or "-m64" is used,

Re: libtool did not search ws2_32.dll

Kuang-Chun Cheng wrote: Hi, I'm using mingw cross compiler (with GNU autotools) under Linux to build DLL. One of the package I build is gnet2-2.0.8 which will link winsock library. Everything is OK, the DLL is created under Linux. When I copy the library to WinXP and use gnet2-2.0.8 to create n

Re: libtool mail lists

Hi Ralf, Ralf Wildenhues wrote: Hi Roumen, * Roumen Petrov wrote on Sat, Jan 09, 2010 at 04:33:00PM CET: This page http://www.gnu.org/software/libtool/ currently refer to site "http://mail.gnu.org/";... for libtool related mail lists . It seems to that correct site is "http:

libtool mail lists

Hi libtool webadmin, This page http://www.gnu.org/software/libtool/ currently refer to site "http://mail.gnu.org/";... for libtool related mail lists . It seems to that correct site is "http://lists.gnu.org/...";. Also not all links point to final location as example "http://lists.gnu.org/pip

Re: rpath

Ralf Wildenhues wrote: * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET: Ralf Wildenhues wrote on 10/12/2009 06:16:40: * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET: Ralf Wildenhues wrote on 08/12/2009 20:13:13: ./configure --prefix=/opt/x/y make make

Re: Multipurpose binaries with different names

Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jan Engelhardt on 7/24/2009 3:25 AM: Hi, when one has a program that does something like if(strcmp(argv[0], "gunzip") == 0) uncompress(); else compress(); GNU Coding Standards frown on this practice: h

Re: d3dx9.lib is not managed by ld, but libd3dx9.a is

Vincent Torri wrote: Hey, I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass -ld3dx9 and i have added everything so that the dll is built. If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual warning message from linker / libtool: *** Warning: linker

Re: purpose of the c wrapper

Ralf Wildenhues wrote: Hello Vincent, Bob, [SNIP] But anyway, I don't see how the current git code generates C wrappers for wince. The host is usually xxx-mingw32ce and will match patterns like {*-}*-mingw*, i.e. it will generate wrappers as for mingw32. But the C-wrapper-code of current

Re: Linking together .dll using .a static libraries

Ralf Wildenhues wrote: * Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET: LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a

Re: Linking together .dll using .a static libraries

LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be "x8

Re: Making .lib import libraries with libtool

LRN wrote: I have a project that uses autoconf/automake/libtool, and it produces shared libraries (on Windows that would be .dll) and static libraries (.a). Which modifications are necessary for it to start outputing .lib libraries (the ones that could be linked with link.exe) along with .dll's?

Re: uninstalled modules do not build .so files

Andy Wingo wrote: Hi, So, this is a resend, as for some reason the silliest of autotools projects creates 300 kB tarballs. Attaching the files individually: unpack in a directory of their own please. *** Unpack the attached tarball (it will create its own directory). It is a standard autotool

Re: libtool.git & cl.exe & Mingw32

Akim Demaille wrote: Hi friends, It's cold, the win32ter's back, and I'm a lonely winderer in the winderful country to losedows. As you suggested, I'm moved from pw32 to ming32, and as a result, I now have a "wrapper.exe" instead of a shell script "wrapper". This is wonderful news, since I

Re: Migrating from 1.5.x to 2.2.x

Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran "autoreconf". "libtoolize" fixed the problem. A concern I have about "libtoolize", it copies "libtool.m4" and lt*.m4 files to my "m4" macro

Re: Getting filenames for libraries

Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: [SNIP] I've attached a sample of the macros if there are comments. e.g. configure.ac (only the interesting bits) [SNIP] LX_PROG_RC use AC_LIBTOOL_RC AC_CONFIG_FILES([src/rsrc.rc]) Makefile.am [SNIP] .rc.lo: $(LIBTOOL) $(AM_

Re: problem when cross compiling with mingw32ce

Vincent Torri wrote: I don't care about that. I just want my executables being installed (copied) in the prefix/bin directory I passed when I exec 'make install'. That's all. WHY does libtool does not want to do so ? Is there a way to forbid libtool executing that wrapper ? like -do-not-exe

Re: problem when cross compiling with mingw32ce

Vincent Torri wrote: On Sat, 6 Dec 2008, Roumen Petrov wrote: You environment lack emulator, or winepath isn't in PATH. WHY do I need an emulator ? I need it to run the project tests including libtool tests. I don't care about that. I just want my executables being install

Re: problem when cross compiling with mingw32ce

Vincent Torri wrote: Hey, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_mem

Re: func_emit_cwrapperexe_src() errors with mingw32ce

Vincent Torri wrote: Hey, Natively, the Windows CE OS has no concept of environment variable. Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because of missing getenv() and putenv() (or setenv() also, of course). I don't know what to do here (removing or not thee calls, as

Re: [PATCH] Don't install .la files when --no-la-files is used

Russ Allbery wrote: Roumen Petrov <[EMAIL PROTECTED]> writes: Russ Allbery wrote: libreadline is linked against libncurses on Debian. Which version ? readline 5.2-3, ncurses 5.7-2. No,no debian version/release. This is an 7(5?) years old linux bug. I'm very dubi

Re: [PATCH] Don't install .la files when --no-la-files is used

Russ Allbery wrote: Roumen Petrov <[EMAIL PROTECTED]> writes: It was old build bug when building readline library on some linux-es. In my memory is suse 7.1 but I'm sure that only this particular version was affected. Many other linux verdors build readline without dependent li

Re: [PATCH] Don't install .la files when --no-la-files is used

Dan Nicholson wrote: On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov <[EMAIL PROTECTED]> wrote: [SNIP] But problem is not in the libtool. Yes it is. If you're linking to libfoo, libtool reads libfoo.la and adds direct links to everything in dependency_libs. Let's say libfoo d

Re: [PATCH] Don't install .la files when --no-la-files is used

Russ Allbery wrote: Roumen Petrov <[EMAIL PROTECTED]> writes: Russ Allbery wrote: When you create a libtool library, libtool records every library against which that library was linked into the *.la file. If you then link another shared library against that shared library using l

Re: [PATCH] Don't install .la files when --no-la-files is used

[SNIP] But problem is not in the libtool. Yes it is. If you're linking to libfoo, libtool reads libfoo.la and adds direct links to everything in dependency_libs. Let's say libfoo depends on libbar and libbaz. You're application ends up directly linking to libfoo, libbar and libbaz instead of ju

Re: [PATCH] Don't install .la files when --no-la-files is used

Russ Allbery wrote: Roumen Petrov <[EMAIL PROTECTED]> writes: Russ Allbery wrote: Debian's experience to date is that --as-needed is buggy and breaks a lot of software, and overall is not a particularly stable solution. Removing *.la files so that the unneeded shared libraries ar

Re: [PATCH] Don't install .la files when --no-la-files is used

Hi Russ, Russ Allbery wrote: Ralf Wildenhues <[EMAIL PROTECTED]> writes: Hello Russ, * Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET: The most frequent problem caused by *.la files is that they add a pile of unnecessary dependencies to shared libraries, which further entangles pa

Re: [PATCH] Don't install .la files when --no-la-files is used

Dan Nicholson wrote: On Mon, Nov 3, 2008 at 2:05 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: [SNIP] Oh, well. You do know that all the linux distros (that I know of) remove the .la files, right? NO I was sort of hoping there would be a nice way to do that. Check content of so called "d

Re: problem when cross compiling with mingw32ce

Vincent Torri wrote: On Tue, 7 Oct 2008, Roumen Petrov wrote: Vincent Torri wrote: Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message

Re: problem when cross compiling with mingw32ce

Vincent Torri wrote: Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link:

Re: MinGW DLLs and autoconf parsing

Jason Curl wrote: Hello, Recently some info was posted about using resource files with Windows compilers. I'm trying to generate a reasonably simple Version resource and there's some information I'm not sure how I can extract from the build process. I'm using libtool-1.5.27a on MSYS-1.0.10 wi

Re: Compiling into chroot

Bernd Jendrissek wrote: On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: Building packages into chroot is more and more common, live-cd, live-usb, initramfs, embedded, vservers etc... A lot of packages use libtool, so using the standard gnu build for chroot environment,

Re: Compiling into chroot

Bob Friesenhahn wrote: On Thu, 12 Jun 2008, Alon Bar-Lev wrote: After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Why not just add a /tmp/device-root sy

Re: Compiling into chroot

Alon Bar-Lev wrote: Hello, I looked at recent libtool-2 versions and could still not find a solution to compile into chroot. I want to create an image to embedded device using a cross compiler. So I do: mkdir /tmp/device-root cd /package1 ./configure --host=<> --prefix=/usr make install DESTD

Re: Separate CPPFLAGS for static and shared libs

Vincent Torri wrote: On Wed, 4 Jun 2008, Ralf Wildenhues wrote: * Vikram Ambrose wrote on Wed, Jun 04, 2008 at 03:54:35PM CEST: However I need to pass separate CPPFLAGS to the objects destined for the shared library as opposed to the objects destined for the library archive. As Andreas al

Re: libtool(2.2.4) detect native java compiler in cross-compilation environment

Ralf Wildenhues wrote: Hello Roumen, * Roumen Petrov wrote on Fri, May 09, 2008 at 09:39:11PM CEST: In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure

Re: libtool(2.2.4) detect native java compiler in cross-compilation environment

Bob Friesenhahn wrote: On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj -> OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like

libtool(2.2.4) detect native java compiler in cross-compilation environment

Hello libtool Team, In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure output I see : checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip ...

Re: Customizing soname

Alon Bar-Lev wrote: On 3/29/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get

Re: Customizing soname

Alon Bar-Lev wrote: On 3/28/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: You request is to change library name. So I could not understand what is related to SONAME. It came as a surprise to me to allow user(verdor) to change library name at configure time. It for generating a dif

Re: Customizing soname

Alon Bar-Lev wrote: On 3/28/08, Peter O'Gorman <[EMAIL PROTECTED]> wrote: -rpath is required for proper execution in many environments, the ability to change the soname is, as far as I can tell, not. Please present a more convincing argument. Hello Peter, I think that infrastructures such

Re: MinGW linux to win32 cross compiler and the test suite

Erik de Castro Lopo wrote: Hi all, I have the beginnings of a solution to this issue. If I hack the libtool generated wrapper script and replace this: exec "$progdir/$program" ${1+"$@"} with WINEDLLPATH="$PATH;$WINEDLLPATH" exec wine "$progdir/$program" ${1+"$@"} My test

Re: libtool windows dll suffix revision

Alon Bar-Lev wrote: On 3/15/08, Peter Rosin <[EMAIL PROTECTED]> wrote: With your suggestion of always using age, you would get dll-7.dll and dll-8.dll for your examples, but you would also get dll-7.dll for my example, and then you would have the same file name for two incompatible dlls, whic

Re: AIX: More troubles

Roumen Petrov wrote: Daniel Sands wrote: I have an executable that dlopens modules, and the modules make use of symbols provided by the executable. Since AIX does not export symbols unless either it has to (if needed for direct linkage to a shared object) or you REALLY want it to (either by

Re: AIX: More troubles

Daniel Sands wrote: I have an executable that dlopens modules, and the modules make use of symbols provided by the executable. Since AIX does not export symbols unless either it has to (if needed for direct linkage to a shared object) or you REALLY want it to (either by -bexpall or by providin

Re: Sun Studio: STL libraries

Tim Mooney wrote: In regard to: Sun Studio: STL libraries, Dan Lacher said (at 12:04pm on Feb...: In trying to resolve a C++ issue within Open MPI we've run into an issue with Libtool automatically linking in Cstd. Because Sun Studio supports two different types of C++ STL libraries (Cstl and

Re: relinking makes libtool link to the wrong library

Simon Josefsson wrote: Hi! We have received a bug report about some parts of recent gnutls (libgnutls-extra.so.26) incorrectly links to the libgnutls.so in /usr/lib/ rather than in $prefix, see original report: http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html To understand

Re: libtool chooses the wrong library version to link against

Peter O'Gorman wrote: Andreas Metzler wrote: Peter O'Gorman <[EMAIL PROTECTED]> wrote: Andreas Metzler wrote: this is about . when I am building gnutls on a system with a different version of gnutls already installed, libtool links the li

Re: C++ Plugins and virtual destructors.

Ralf Wildenhues wrote: * Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET: Here's a relevant post from the GCC list; it mentions how to work around some dlopen difficulties (including RTTI, exceptions, custom new/delete). http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html

Re: Libtool modules and symbol clashes

Russ Allbery wrote: "Simon White" <[EMAIL PROTECTED]> writes: However if one of those modules internally calls a function that is also marked as being exported it does not necessarily call the function in its own library. Depending on order it may call the function that exists in the other

Re: Libtool doesn't set -rpath automatically when needed?

Usually /etc/ld.so.conf contain /usr/local/lib. Dunno why this path is not set on you host. Benoit SIGOURE wrote: Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/local/lib (pre-built binaries: http://w

Re: Windows DLLs from Unix with minimum effort

Jason Curl wrote: Roumen Petrov wrote: [SNIP] Well, I think I've figured it out today (albeit I'm testing on a different machine, similar software though) and there are two executables. One in the build directory and one in .libs. e.g. src/ .libs/ libmofo-1.dll test/ l

Re: Windows DLLs from Unix with minimum effort

Jason Curl wrote: Brian Dessent wrote: Jason Curl wrote: ./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at" --target=i586-pc-mingw32 --disable-static on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of bui

Re: How to create shared library(dll) without lib prefix ?

ge creator(distributors) can decide how to create dlls. Please comment, Roumen Roumen Petrov wrote: Let a project use libtool to make libraries. In case of mingw build (cross-compilation) in many cases is good dll to be without lib prefix. In these cases cross-compilation can create dlls with sam

How to create shared library(dll) without lib prefix ?

Let a project use libtool to make libraries. In case of mingw build (cross-compilation) in many cases is good dll to be without lib prefix. In these cases cross-compilation can create dlls with same names as native build and those dlls can be used instead native build. The name of import librar