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. > >

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

> Message: 1 > Date: Sat, 15 Aug 2009 21:41:26 +0200 > Subject: Re: global_symbol_pipe not picking up an initialized global > variable with msvc > Message-ID: <4a870f66.1080...@lysator.liu.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Den 2009-08-14 23:41 skrev David

RE: cccl usage

> > Den 2009-01-07 20:24, skrev Peter Rosin: > > Den 2009-01-07 20:07 skrev Ralf Wildenhues: > >> Hi Peter, > >> > >> * Peter Rosin wrote on Wed, Jan 07, 2009 at 02:09:38PM CET: > >>> Ralf, I have a vague memory of you mentioning that you knew of a > >>> project that was using cccl to provide its

RE: Using libltdl with the Microsoft compiler

> > * Braden McDaniel wrote on Fri, Jun 20, 2008 at 10:20:13PM CEST: > > Ralf Wildenhues wrote: > >> * Braden McDaniel wrote on Fri, Jun 20, 2008 at 11:03:04AM CEST: [snip] > > Yes, unfortunately there is still a ways to go. Btw. @Ralf: how is integration of the windows patchery going? :) has th

RE: Using libltdl with the Microsoft compiler

> [snip] > > Historically (i.e. prior to libtool 2.x), I've found that those shell > environments have not been up to the task of building my project with > the Microsoft compiler. So I've maintained a Visual C++ project file > build for that compiler. I've just recently started using libltdl in

RE: [patch/rfc] setting version type based on vendor

Hi! Ralf Wildenhues <> wrote: > Hello Mike, > > Please post patches to the libtool-patches list in the future, thanks. > > * Mike Frysinger wrote on Sat, Feb 16, 2008 at 09:48:52AM CET: >> i dont know if there's a policy on this, but we've been treating the >> shared libraries in the Gentoo/Free

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >> You have several options to avoid this failure: >> >> - find out why timestamps are not in the right order after >> libtoolize --ltdl=sub/ltdl >> >> (inside s

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > You have several options to avoid this failure: > > - find out why timestamps are not in the right order after >libtoolize --ltdl=sub/ltdl > > (inside sub/ltdl, configure.ac should come before aclocal.m4 should > come before configure and Ma

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >> >> Thanks, I forgot about the need to 'make install' first. >> >> Does ls have an option to show full time stamp resolution? If yes, >> please repeat the a

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > > Thanks, I forgot about the need to 'make install' first. > > Does ls have an option to show full time stamp resolution? If yes, > please repeat the above after 'rm -rf t', using the option with both > ls invocations. Ok, i added --full-time.

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > > Hi Ralf! > > Since the commands reported errors/warnings at first, i did a gmake > install before repeating. I attached both logs. Hi! I finally found the real error :) Seems i was just

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > Please enter the top build directory, execute these commands, and post > log-interix1.gz: > > ( mkdir t > cd t > ../libtoolize --copy --ltdl=sub/ltdl > ls -lart sub/ltdl > rm -rf sub > ../libtoolize --ltdl=sub/ltdl > ls -lart sub/ltdl > cd ../tes

Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Hi! I have ported (again) libtool to windows using parity. No I'm stuck with the last three testsuite failures, which I just can't find causes for... Could you please have a look at this? I also attached the patch I use to get things rolling :) I plan to add some more comments, etc. So this is no

RE: HEAD testsuite.

Gary V. Vaughan <> wrote: > Hi Markus, > > On 6 Feb 2008, at 22:17, Duft Markus wrote: > >> Hi all... >> >> Could it be, that the autotest testsuite behaves badly if building >> out-of-source? I'm getting a whole bunch of file not founds with >&

Native Windows through parity

Hi there (again :))! I have a few patches for libtool in my queue again :) * 1.5.24 -> all tests passed * 1.5.26 -> all tests passed * HEAD (2.1c) -> all classic tests passed, log for new testsuite attached. I hope this time they will make it into CVS :) For HEAD, I'

RE: HEAD testsuite.

Hi Another one... The "run" scripts for the failed tests seem to miss some quoting (for exmaple my preprocessor is -E, so i get: testsuite: invalid option: -E... Cheers, Markus Duft Markus <> wrote: > Hi all... > > Could it be, that the autotest testsuite behaves b

HEAD testsuite.

Hi all... Could it be, that the autotest testsuite behaves badly if building out-of-source? I'm getting a whole bunch of file not founds with relative paths within the source dir. If yes, for now I will finish my libtool port with building inside the source dir, so I manage to fugure out which fai

RE: mingw install directory for shared lib

Bob Friesenhahn <mailto:[EMAIL PROTECTED]> wrote: > On Wed, 9 Jan 2008, Duft Markus wrote: > >> Bob Friesenhahn <> wrote: >>> On Tue, 8 Jan 2008, Ralf Wildenhues wrote: >>>> >>>> General question before fixing this: on w32, should even pl

RE: mingw install directory for shared lib

Hm, sorry, as i reread my mail, i realized that the text is in the wrong position ;) of course my comment is targeted ar bob's text, not ralf's question... Duft Markus <> wrote: > Bob Friesenhahn <> wrote: >> On Tue, 8 Jan 2008, Ralf Wildenhues wrote: >>>

RE: mingw install directory for shared lib

Bob Friesenhahn <> wrote: > On Tue, 8 Jan 2008, Ralf Wildenhues wrote: >> >> General question before fixing this: on w32, should even plugins have >> their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the D

RE: Avoid la files.

Good Morning ;) Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > * Duft Markus wrote on Thu, Dec 13, 2007 at 11:27:34AM CET: >> >> I'm not sure if i can easily put in HEAD, we use 1.5.24. Would it be >> enough to get HEAD built somewhere, and bootstrap on

RE: Avoid la files.

rnings in the output, they're fixed already ;o) And thanks for the fast reaction... ;o) Cheers, Markus Ralf Wildenhues <> wrote: > Hello Markus, > > Thanks for the report. > > * Duft Markus wrote on Thu, Dec 13, 2007 at 10:34:16AM CET: >> >> I have a

Avoid la files.

Hi All! I have a quick question about libtool: What can I break, if I fool libtool into thinking that there are no .la files for any library on the command line? The background: We have a bunch of software (about 1000 libraries) which are linked (shared) together in one executable. If manually li

RE: passing flags to the librarian

Hi! 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). Also parity comes with a patch for libtool to behave nicely, and i also have a bunch of patches we requi

RE: Relinking issue

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > Hello Markus, > > * Duft Markus wrote on Tue, Oct 09, 2007 at 09:25:15AM CEST: >> >> Regarding CVS HEAD: since this is all for production use on many, >> many platforms, i can't upgrade (it's simply n

RE: Relinking issue

Hi Ralf! >> Somehow executables are still relinked, and i just can't find the >> place where this happens. Something in the back of my mind tells me >> that it has something to do with the lt-${name} executables, could >> this be correct? > > It's the other way round: because relinking is done, t

RE: Relinking issue

Sorry, forget this post, i found out that it is still relinking libraries too... Cheers, Markus Duft Markus <> wrote: > Hi! > > I'm again having issues with relinking: I have > shlibpath_overrides_runpath set to yes (which is really true now for > my compiler),

Relinking issue

Hi! I'm again having issues with relinking: I have shlibpath_overrides_runpath set to yes (which is really true now for my compiler), which effectively prevents relinking, but only of libraries. Somehow executables are still relinked, and i just can't find the place where this happens. Something

RE: Question about shlibpath_overrides_runpath / relinking

Ralf Wildenhues <> wrote: > Hello Markus, > > * Duft Markus wrote on Mon, Oct 01, 2007 at 01:55:55PM CEST: >> >> Still i feel, that relinking should not be neccessary with my >> compiler [...] Is there any other way to tell libtool, that it >> should no

Question about shlibpath_overrides_runpath / relinking

Hi together! I have a question about relinking. I'm porting libtool 1.5.24 to a compiler which uses microsoft's cl.exe in the background. I have all libtool tests passing right now. Still i feel, that relinking should not be neccessary with my compiler (it supports hardcoding correctly, LD_LIBRAR

Possible bug regarding exeext

Hi! I believe i found a bug regarding exeext in libtool. When generating the tag configuration to the "libtool" script there is a line: exeext="$exeext" Which seems wrong, since nowhere ever $exeext is set. When changing $exeext to $ac_exeext everything works fine, and the final libtool script h

Relinking on windows

Hi together! I have a question regarding relinking on windows (while installing). Everytime a library/exe is installed it is relinked, which costs tons of time. After thinking about the problem of having to relink (i assume because of changing runpaths?) i realized that a Makefile target (pointin

RE: Support for VC++ toolchain (was Re: Absolute pathsgeneratedbylibtool.)

Olly Betts <> wrote: > On 2006-11-28, Duft Markus <[EMAIL PROTECTED]> wrote: >> If you could tell me how i can bring outlook to do so, i will gladly >> ;o) > > Off-topic, but in the interests of improving the readability of this > list (and others!): >

RE: Windows C++ support impossible?

Howard Chu <> wrote: > Duft Markus wrote: >> Are there any opinions on this. Should i simply say, that this >> libtool feature is not available with wgcc/windows? This would mean, >> that i would have to somehow disable *all* code generation in >> libtool... Are

Windows C++ support impossible?

Hi again! While thinking about the C++ support on windows, i stumbled over a problem i had with WGCC a while ago. C++ mangled names are not valid C identifiers. This doesn't sound too bad, but it really is. Since they are not valid identifiers, one cannot generate a C-source file that contains suc

RE: Libtool HEAD testsuite

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > * Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET: >> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >>> * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET: >>>> >>>> Sorr

RE: Libtool HEAD testsuite

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > Hello Markus, > > * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET: >> >> Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as >> far as my situation is concerned, completely in the wron

Problem with post(un)install cmds

Hi! I wrote the following two for libtool 1.5.22 and they worked perfectly. Now i just copied them over to libtool 2.1a (CVS HEAD), and it doesn't seem to work (the directory structure is the same, so this is ok...). I believe that there is a difference in how libtool executes these code snippets,

RE: windows static archive, missing symbols

Howard Chu <> wrote: > Bob Rossi wrote: >> Hi, >> >> I've got a quick question hopefully. I'm building pcre on windows. >> I've >> been able to build it into a dll and link against it with a small >> program. However, when I build a static library, and link it with a >> small program, I get the m

RE: Libtool HEAD testsuite

a workaround I think there is some work to be done here.... ;o) Cheers, Markus Duft Markus <> wrote: > Hi! > > I'm currently working on porting my wgcc patches from 1.5.22 to HEAD > (*pfff*). Now recently i changed the default output of wgcc to a.exe, > so i have an

Libtool HEAD testsuite

Hi! I'm currently working on porting my wgcc patches from 1.5.22 to HEAD (*pfff*). Now recently i changed the default output of wgcc to a.exe, so i have an extension for my exe's, since otherwise they don't really work that good in some cases ;o) However, no i realized, that the whole libtool tes

Wgcc critical bugfix!

Hi! The yesterday-released version of wgcc (2.1.0) has a critical bug, making it crash whenever you pass certain options (like -O2) to it. This has been fixed in 2.1.1 which is available now from SF.net. Cheers, Markus ___ http://lists.gnu.org/mailman

wgcc 2.1.0 released

Hi together! I'm proud to announce the 2.1.0 "stabilizing release" of wgcc. For more info read below. Cheers, Markus == wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft T

RE: Support for VC++ toolchain (was Re: Absolute paths generatedby libtool.)

Hi! Hmmm, what do you mean with "wgcc doesn't set the environment"? It's true, wgcc doesn't, but why should it?? The thing is, that wgcc should be the only one to run cl.exe, and he knows how... Am i missing something? Could be, that wgcc doesn't work that good under cygwin yet, since the primary

RE: Support for VC++ toolchain (was Re: Absolute paths generatedbylibtool.)

= Hope this helps! Cheers, Markus -Original Message- From: Benoit Sigoure [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 3:43 PM To: Duft Markus Cc: libtool@gnu.org Subject: RE: Support for VC++ toolchain (was Re: Absolute paths generatedbylibtool.) Quoting Duft Markus <[EM

wgcc 2.0.5 released

I am very proud to announce the release 2.0.5 of wgcc. Maybe there is some interest. It is a very much improved version compared to the previous ones. List of changes below. Cheers, Markus wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce n

RE: Absolute paths generated by libtool.

We could talk about it if you would be able to talk like a grown up... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Wednesday, November 15, 2006 8:17 AM To: libtool@gnu.org Subject: Re: Absolute paths generated by libtool. Duft

RE: Absolute paths generated by libtool.

Hey! You may want to look at www.sf.net/projects/interix-wgcc. If using interix is an alternative for you, i think wgcc is a cool tool (which, of course, i wrote ;o)). Using interix is good in any case, because it is more stable and faster than cygwin. Additionally cygwin does not correctly work o

Wgcc 2.0.2 released.

wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain), and to mimic the behaviour of the GNU compiler collection. This means that wgcc understands many of GCC's command line argu

New libtool patch for new wgcc.

Hey together! For all interested in this, i released a new patch for libtool 1.5.22 to work with the current wgcc. Both is brandnew and can be found on sourceforge. Current wgcc version is 2.0.1 and the patch has the date 27.09.2006. This fixes some minor things and makes things a little cleaner

Hardcoding paths.

Hi again! With wgcc (again ;o)) i now tell libtool, that hardcoding is "unsupported". Configure tells this too now, so everything seems to be ok. But when i run hardcode.test: = Searching for hardcoded library directories in each program .libs was not hardcoded in `hc-direct', as libtool expected

Wgcc status report

Hey again! Wgcc status report ;o) (this is rc4 with libtool patch from today): PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-mak

FW: [wgcc-dev] Dlpreopen on windows

Hey together ;o) I again played a little with dlpreopening on windows (with wgcc). Now i again know why it didn't work ;o) Libtool generates a symbol table on the fly which it then compiles and links in, correct? That symbols table contains both .text and .data symbols. There is no problem with .

Dlpreopen on windows

Hey together ;o) I again played a little with dlpreopening on windows (with wgcc). Now i again know why it didn't work ;o) Libtool generates a symbol table on the fly which it then compiles and links in, correct? That symbols table contains both .text and .data symbols. There is no problem with .

Wgcc 2.0 RC2 released.

wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain), and to mimic the behaviour of the GNU compiler collection. This means that wgcc understands many of GCC's command line argu

RE: AW: boost ?!

2 PM To: stdcxx-dev@incubator.apache.org Subject: Re: AW: boost ?! Duft Markus wrote: > OMG, i'm so blind.. I messed up 12d and 15d, maybe those should get other > names ;o) now it's all clear why it can't work Yes, container iterators have different types between d

RE: [boost] wgcc 2.0 RC1 released

Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendon Costa Sent: Wednesday, September 20, 2006 10:43 AM To: David Abrahams Cc: boost@lists.boost.org; libtool@gnu.org Subject: Re: [boost] wgcc 2.0 RC1 released David Abrahams wrote: > "Duft Markus" <[EMAI

AW: wgcc 2.0 RC1 released

liche Nachricht- Von: Albert Chin [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 17:03 An: Duft Markus Cc: libtool@gnu.org Betreff: Re: wgcc 2.0 RC1 released On Tue, Sep 19, 2006 at 11:05:25AM +0200, Duft Markus wrote: > > For all interested in native Windows binaries

AW: [boost] wgcc 2.0 RC1 released

ost@lists.boost.org Cc: libtool@gnu.org Betreff: Re: [boost] 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

wgcc 2.0 RC1 released

Hi again!   For all interested in native Windows binaries built with Autotools and mnay other interesting things:   wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain),

wgcc-2.0-pre.7

Hi everybody! i'm proud to announce that wgcc-2.0-pre.7 and it's documentation have been released. This version is close to the first RC and is capable of building (with little or no modifications) OpenLDAP, OpenSSL, libtool, zlib, Berkeley DB, expat, gettext, libiconv, pkgconfig, glib, lib

wgcc critical update

hey everybody.   there was a really bad, bad, bad malloc in all 2.0-pre.x versions, which is fixed in wgcc-2.0-pre.3. there was one byte missing in the alloc, which caused unpredictable behaviour (core dumps) when processing command outputs.   i.e. when cl.exe & co. didn't output anything,

wgcc v2 first release

phuu   wgcc-2.0-pre.1 officially released at sourceforge, for those interested. here some notes:   wgcc-2.0-pre.1: brandnew codebase, everthing got better ;o) supports many new things, but whats even better, all the old stuff still works as expected... everything just got really much mo

windows and dlopen

hi there!   i'm currently working on wgcc v2 and the libltdl behaviour on windows. looking at mdemo-static.test and co. i have a little problem. since all libs are linked in static, the symbols which are looked up are contained in the executeable itself, so my idea was to dlopen the execute

AW: improve support for building DLLs on cygwin and mingw

No. __declspec(dllimport) tells the compiler that an indirection is needed. The compiler will simplify '&externvar' to '_imp__externvar'. There is one _imp__externvar per library, but all their values are the same. The "same function name, different address" problem will occur - as far as I und

AW: improve support for building DLLs on cygwin and mingw

Hi there! I implemented wgcc (a compiler wrapper behaving like gcc but calling cl.exe). Since the target should be to compile sources with minimum changes i have done lot's of work for this. The only thing one has to do with wgcc is: Define a macro like MYPROG_EXPORT to __declspec(dllexport) wh

Recheck Bug...

Hi!   Seems i was wrong with the recheck bug. Whenever i reconfigure in a directory where i allready configured libtool i get this:   rm -f ltmain.shTdate=`/bin/sh ../libtool-1.5.22/mkstamp < ../libtool-1.5.22/ChangeLog` &&  sed -e 's/@''PACKAGE@/libtool/' -e 's/@''VERSION@/1.5.22/'  -e "s%@

Recheck Bug??

Hi together!   seems i found a little ... äähmm ... bug(??) ;o) when i do:   $ CC=wgcc CXX=wgcc LD=wgcc ../libtool-1.5.22/configure --prefix=/wamas/libtool/test/binary   and after that bootstrap libtool, and do "$ gmake" libtool trys to recheck with:   $ gmake/bin/sh ./config.status --rec

Interix, libtool, wgcc

Hey all!   After some hard work, i've released another version of wgcc (see sourceforge, "interix-wgcc") which now has some major improvements for shared libraries (and static ones, and mixing both types of libraries), it even generates some assembler code on the fly while linking. ;o)

PATH as runpath_var?

Hi!   Just a quick question: On windows all the compiled .dll files need to be in the path to be found at runtime ($PATH). Is there some easy way of putting paths in there? Like just changing runpath_var to PATH??   Regards, markus ___ http://list

AW: Interix Shared Libraries

== 1 of 112 tests failed Please report to bug-libtool@gnu.org gmake[2]: *** [check-TESTS] Error 1 gmake[1]: *** [check-am] Error 2 gmake: *** [check-recursive] Error 1 Regards, Markus -Ursprüngliche Nachricht- Von: Ralf Wildenhues [mailto:[EMAIL PROT

AW: Interix Shared Libraries

enstag, 4. Juli 2006 13:00 An: Duft Markus Cc: libtool@gnu.org Betreff: Re: Interix Shared Libraries Hello Markus, * Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST: > > To bring some (good) news (i think ;o)). I wrote a little compiler > wrapper you may have heard of -> wg

Interix Shared Libraries

Hey ho ;o)   To bring some (good) news (i think ;o)). I wrote a little compiler wrapper you may have heard of -> wgcc (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and uses microsofts toolchain in the background. As of 0.6.0 the shared library support is quite stable. I

AW: libtool + MinGW

) Regards, markus -Ursprüngliche Nachricht- Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED] Gesendet: Montag, 12. Juni 2006 08:28 An: Duft Markus Cc: Brendon Costa; libtool@gnu.org Betreff: Re: libtool + MinGW * Duft Markus wrote on Mon, Jun 12, 2006 at 08:24:00AM CEST: > > Do you want t

AW: libtool + MinGW

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 allready talked about wgcc, did we? ;o) Regards, Markus -Ursprüngliche Nachrich

Re: MSVC Support

Hi there! You may want to have a look at http://www.sourceforge.net/projects/interix-wgcc which is a MSVC wrapper i wrote. It feels just like gcc, or at least it should ;o). So far everything works fine (i'm using interix / SUA, but cygwin port should be very easy). I'm just about looking into sha