[Top][All Lists]
[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
lt-1.5.24-parity.patch
Description: lt-1.5.24-parity.patch