libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Windows DLLs from Unix with minimum effort


From: Duft Markus
Subject: RE: Windows DLLs from Unix with minimum effort
Date: Mon, 5 Nov 2007 08:01:02 +0100

Hi!

You might want to take a look at parity (http://www.sf.net/projects/parity). 
This has been written exactly - and only - for the purpose of compiling native 
windows programs from a UNIX-style environmet (currently only Interix is fully 
supported).

It also comes with a libtool patch, which makes it play together fine (all 
tests passed). Together with libtool i'm currently building about 6GB of object 
files a day on windows ;o) - and all is shared libraries!

If you've got any questions, just ask!

P.S.: @libtoolers(ralf): could you have a look at the patch, if maybe this one 
could make it into libtool? ;o) I've attached it. Maybe there are some tweaks 
to-do...

Cheers, Markus

Jason Curl <> wrote:
>>>   libtest.exe      <-- Doesn't seem to work? No idea
>>>                        what this is...
>>>   libtest
>>>   .libs/
>>>     libtest.exe    <-- Will work when "libmofo-1.dll"
>>>                        is in the path, e.g. copied to
>>>                        this dir.
>>> 
>>> Can anybody explain what libtool is doing?? It appears to do a lot
>>> of nifty stuff, but I don't see any dependencies on "libmofo" from
>>> "libtest.exe" in either case. I'll attach a minimal example when I'm
>>> back at work tomorrow.
>> 
>> It is a wrapper to allow running the uninstalled binary in the build
>> tree without having to mess with PATH or LD_LIBRARY_PATH or whatever.
>> On a POSIX system this would be a shell script.  I think that in
>> libtool HEAD, it won't have such a confusing name.
>> 
>>> And the directory it runs from (.libs) indicates it is actually the
>>> source "lt-libtest.c" that relies on a shell, so as soon as I move
>>> the executable to a "virgin" computer without Cygwin, the program
>>> "libtest.exe" won't work.
>> 
>> You shouldn't be manually mucking about like that, you use "make
>> install" to get an installed copy and that will not be a wrapper.  If
>> you configured with CC="gcc -mno-cygwin" (i.e. used this "fake mingw"
>> setup) then the Cygwin dependence should only be for the wrapper
>> which isn't supposed to be installed or even moved out of the build
>> directory for that matter.
> 
> For Posix systems I agree (and I haven't had to care until now). It's
> an unnecessary burden for w32api however, especially for users that
> don't have any kind of sane build environment. I guess I'm saying I
> don't know how to package the result so that someone on w32 can use
> it on a standard cmd.exe console without having Cygwin, etc.
> installed. This environment is only necessary for the build. Or
> should I revert to a different build environment? This is my first
> attempt at using Autoconf to build something for native Windows
> (mostly because I want to use it on Linux, but other colleagues of
> mine benefit from it's use on Windows).         
> 
>> 
>>> I'd also like to generate .lib files (what is the .a file that is
>>> generated anyway? Is that the .lib import library?)
>> 
>> An import library can be named foo.lib, libfoo.a, or libfoo.dll.a;
>> they are all the exact same thing just named differently.  Don't
>> confuse the libfoo.a name with a static library which has the same
>> style name but is a totally different thing (and that's why it's
>> considered deprecated to name an import library libfoo.a, but some
>> are still done that way, e.g. all of w32api.) 
>> 
>> Brian
> 
> 
> Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen +
> telefonieren 
> ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE
> NEUEINSTEIGER 
> Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket
> für clevere Doppel-Sparer, nur  29,95 €  inkl. DSL- und
> ISDN-Grundgebühr! 
> http://www.arcor.de/rd/emf-dsl-2
> 
> 
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool


-- 
14. November 2007 
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien, A 

5. Dezember 2007
Salomon Automation am  Schweizer Forum für Logistik, Lausanne, CH




Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht für Zivilrechtssachen Graz

Attachment: lt-1.5.24-parity.patch
Description: lt-1.5.24-parity.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]