[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Patches to support cross-compile with cygwin host
- To: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Subject: Re: [Patches] Patches to support cross-compile with cygwin host
- From: Ryan Johnson <ryan.johnson@xxxxxxxxxxxxxx>
- Date: Tue, 27 Mar 2012 19:59:49 -0400
On 27/03/2012 6:46 PM, Joseph S. Myers wrote:
Fair enough. I don't remember where I got the original patch from (years
ago) -- some mailing list's archives, most likely -- but I just added
the windows/cygwin conditionals following the existing patches' use of
Darwin/FreeBSD conditionals. I lack the autotools-fu to create the
feature test from scratch, though.
On Tue, 27 Mar 2012, Ryan Johnson wrote:
At the request of the folks at crosstool-ng.org, I'm attaching three small
patches for eglibc-2.12 that allowed me to bring up an
x86_64-unknown-linux-gnu toolchain (gcc-4.5.3 and 4.6.1) on both cygwin-1.5
and 1.7 hosts. I suspect the patches will work for other eglibc versions as
well, but I haven't tested that.
I don't think conditionals on the build system OS are a good idea; the GNU
practice is to use feature tests where necessary instead.
Disabling i18n would probably remove the need for the two *libintl.patch
files, which fix linker errors involving -lintl; the third patch
(bsd-u_char) resolved type-already-defined errors; I forget which system
header contained the original definition, but it gave virtually
identical typedefs to the ones in sunrpc/rpc/types.h; the patch just
copies verbatim the #ifdefs that guard the original definition.
I've been gradually working on merging the cross-rpcgen changes to FSF
glibc; my most recent version,
<http://sourceware.org/ml/libc-alpha/2012-03/msg00375.html>, disables i18n
for the cross-rpcgen, which might help with avoiding libintl dependencies
there (or maybe further i18n disabling is needed as well - you didn't say
anything about what the actual problems are that your patch is addressing
or why you chose a particular approach).
In any case, the patches are mostly intended to identify the problem and
show where the solution lies; I'll leave the polishing to someone more
adept at autotools hacking than I am.
Patches mailing list