[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Libtool 1.5.23b, Windows and WGCC
From: |
Duft Markus |
Subject: |
Libtool 1.5.23b, Windows and WGCC |
Date: |
Fri, 4 May 2007 11:29:51 +0200 |
Hi!
After adding some shiny new parts to WGCC i thought, i may do a fresh
WGCC port of libtool 1.5.23b, so we can use it in our company. This one
is much cleaner then the last port.
I Cc'd this mail to the libtool list too, since there seems to be some
interest in Windows building right now... ;o)
FYI: WGCC now supports hardcoding paths on windows, and some other
interesting stuff, thats also the reason, why now *all* tests pass
(results attached).
There would have been a test.winnt.log too which differs from the
interix test-suite run only in that configure got
"--build=i586-pc-winnt". The results are the same, all test pass. I
didn't attach the log, since it nearly has the same content, and is not
too small ;o)
The patch is written to work with WGCC >= 2.2.0 (which will be released
in the next days), but most (not hardcoding) will also work with older
WGCC versions.
Another Question: With WGCC comes along the utility wchrpath to change
the runpath of a binary on-the-fly (just like chrpath on Linux). Would
it be a big deal to just use wchrpath instead of relinking when
installing a binary?
Also, since i now with WGCC had a deeper look at generating stuff very
similar to libtool's preload tables, i realized, that libtool won't ever
work with C++ on windows the way things are done right now. This is
because the Microsoft C++ name mangling creates names that are not valid
C Identifiers, which means, one cannot generate a C source file which
contains pointers to such symbols. WGCC solves this, by generating a
COFF object file directly (in older versions, by generating ana ssembler
source, and compiling it on-the-fly).
Are there any thoughts about this? I don't think that this is too
critical, since i never saw a package using this (except for the libtool
tests, but those are plain C anyways... ;o))
Another Windows issue is, that as soon as it comes to a little more
sofisticated shared library dependencies, where global data symbols are
involved, the only way to get things compiles correctly, is to force the
compiler into C++ mode. This is, because imported data symbols are (of
corse) non-constant initializers for global data. The Microsoft Compiler
(and GCC too, for that one) cannot compile such a constellation as C
code.
Could please anybody have a quick look at this and give me some
feedback?
Thanks in advance,
Cheers, Markus
--
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz
libtool-1.5.23b-wgcc-2.2.patch.gz
Description: libtool-1.5.23b-wgcc-2.2.patch.gz
test.interix.log.gz
Description: test.interix.log.gz
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Libtool 1.5.23b, Windows and WGCC,
Duft Markus <=