libtool
[Top][All Lists]
Advanced

[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

Attachment: libtool-1.5.23b-wgcc-2.2.patch.gz
Description: libtool-1.5.23b-wgcc-2.2.patch.gz

Attachment: test.interix.log.gz
Description: test.interix.log.gz


reply via email to

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