Libtool -release and static libraries.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am using libtool version 1.5.18 to create a library I wrote for unit testing. It has come to the stage where I would find it useful to have multiple versions of this library installed at any point in time on my machine. I had a look

Re: Libtool -release and static libraries.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: > Since you seem to want libatcppunit-1.0.6 to be the library name, I suggest > that you use it as the library name :) > > lib_LTLIBRARIES = libatcppunit-1.0.6.la > > This means that the libatcppunit.so symlink will also disappe

Re: Libtool -release and static libraries.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Sorry, that makes no sense : the substitutions are done at configure time, > > Automake is run earlier and will never know their values. > > >> >> However in the automake files I am unable to use these variables for >> >> substitution on the left

Re: Libtool -release and static libraries.

I just noticed that the messages that i have sent are coming through slightly corrupted. I am going to have to find out what is causing the corruption when i get back to work, but anyway. The automake variables i have provided are being replaced with: address @ hidden @ That is not what they are

MSVC Support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I have been looking on the web and in the libtool manual for any information about support for using libtool with MSVC but have found very little. There have been a few posts to the libtool patch list, but I cant find anything substant

Re: MSVC Support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Surely that is very helpful. Is there a reason you're not contributing > them to cccl though? I'm asking because: if we end up with several of > such wrappers being used widely, Libtool may have to end up supporting > several, possibly slightly inc

Re: libtool + MinGW

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: > I'm not sure why you are getting the link errors about duplicated > symbols, but your testcase in general is not doing what you think it's > doing. You'll note that there is not a DLL created anywhere, and this > is because you

Re: MSVC Support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> I will try to have a look at the patch later on tonight (If I get some >> time after work). If it is just regressions that need to be tested and >> there is an appropriate set of tests then I can run it on Windows >> using MSVC, and MinGW and on Net

Re: libtool + MinGW

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: > * Brendon Costa wrote on Fri, Jun 09, 2006 at 03:58:24PM CEST: >> As part of my quest to get libtool and MSVC working together, i thought >> i would first get libtool working with an example project on a few o

Re: libtool + MinGW

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: > No, your example was flawed because it did not pass -no-undefined, which > means you get static libraries unconditionally. If you fix that, then > libtool builds both shared and static versions of the library, and it > successfu

Re: AW: libtool + MinGW

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duft Markus wrote: > Hi! > > Do you want to get it to work with the MinGW GCC, or with the MSVC toolchain > (i.e. cl.exe, link.exe etc...) ? This makes a big difference, since libltdl > is really useless with the MS toolchain. > > I think we allrea

Re: [boost] wgcc 2.0 RC1 released

David Abrahams wrote: > "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

Windows paths not considered abolsute in -rpath

Hi, I am not entirely sure if this is the correct behaviour for libtool or not, but if i compile a program that supports cross compiling using libtool like: /path/to/configure --prefix=C:\\msys\\1.0\\blah DESTDIR=/home/bcosta/i386-mingw32 --host=i386-mingw32 make it get an error while it

Re: Windows paths not considered abolsute in -rpath

Ralf Wildenhues wrote: (Side note: I do hope your cross-compiler is named something like i386-mingw32-g++ rather than plain g++.) Actually I am using the non-prefixed version. I guess i should use the prefixed version to avoid possible confusion huh... Thanks, Brendon. _

Link error for blahS.c when used in multiple GCC environment.

Hi, I am having troubles linking an application in a project that uses libtool in an environment that has two versions of the GCC compiler. In normal situations (Single compiler installed) this project builds and runs fine. However this project is used as a demonstration for a source analysis pro

Re: Link error for blahS.c when used in multiple GCC environment.

Albert Chin wrote: > On Sat, Mar 31, 2007 at 11:53:12AM +1000, Brendon Costa wrote: >> Development GCC that i compile from GCC 4.0.1 sources: >> Version: 4.0.1 >> Prefix: /home/bcosta/build/install_gcc >> libstdc++: /home/bcosta/build/install_gcc/lib/libstdc++.so >

Re: Link error for blahS.c when used in multiple GCC environment.

tatic.a' extracting global C symbols from `/home/bcosta/gcc/install/lib/libstdc++.a' (cd .libs && gcc -c -fno-builtin "library_userS.c") rm -f .libs/library_userS.c .libs/library_user.nm .libs/library_user.nmS .libs/library_user.nmT g++ -g -O2 -o .libs/library_user library_use

Re: Link error for blahS.c when used in multiple GCC environment.

Ralf Wildenhues wrote: > * Brendon Costa wrote on Mon, Apr 02, 2007 at 11:42:29PM CEST: >> Ok, I installed libtool 1.5.23b and re-bootstrapped my example project. > > Thanks for all the data. Upon reading, I'm a bit embarassed to see that > I could have asked a better

Re: Link error for blahS.c when used in multiple GCC environment.

Ralf Wildenhues wrote: > * Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST: >> They are both C++ libraries yes. I do not tell either of them to link >> with libstdc++ explicitly. The linking lines for the libs are below. > > Libtool gets the libstdc++ part in, fo

Re: Link error for blahS.c when used in multiple GCC environment.

libmystatic and then goes to libstdc++ to find the symbols but is looking at the incorrect library instance? Thanks, Brendon. Brendon Costa wrote: > Ralf Wildenhues wrote: >> * Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST: >>> They are both C++ libraries yes. I d

C++ Plugins and virtual destructors.

Hi all, Is using virtual destructors fine with a C++ plugin interface? I have an example below that works. However i am not sure if it is a good practice. In particular is it ok to make use of virtual destructors in an application to destroy an object allocated in the plugin or should I define a

Re: C++ Plugins and virtual destructors.

Ralf Wildenhues wrote: > Hello Brendon, > > Means you've got it to work with which set of compilers on what list of > systems? Just GCC 4 on Linux. I haven't tried any others yet. > I don't know either. But if it helps you, we can put your example in > the Libtool HEAD testsuite, to get some t

Re: C++ Plugins and virtual destructors.

> If the vtable is functioning for normal virtual functions, why wouldn't > it also work for a virtual destructor? Destructors are not magic; they > are merely functions that get called just before memory is released. > RTTI, a common culprit in dlopen issues, doesn't get involved here. > I can

Re: C++ Plugins and virtual destructors.

Bob Friesenhahn wrote: > On Sun, 11 Nov 2007, Daniel Herring wrote: >> >> If the vtable is functioning for normal virtual functions, why >> wouldn't it also work for a virtual destructor? Destructors are not >> magic; they are merely functions that get called just before memory is >> released. RT

Re: C++ Plugins and virtual destructors.

Bob Friesenhahn wrote: > On Mon, 12 Nov 2007, Brendon Costa wrote: >> >> * As for exceptions, I have defined all the methods for the plugins >> interface as throw() so exceptions may occur inside the plguin but may >> not propagate from the plugin to the application.