bug-gnulib
[Top][All Lists]
Advanced

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

Re: MacOSX Leopard gcc-4.2 build problems with coreutils-7.0 and its gnu


From: sci-fi
Subject: Re: MacOSX Leopard gcc-4.2 build problems with coreutils-7.0 and its gnulib
Date: Tue, 18 Nov 2008 12:03:52 -0600

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Thank you-all for responding.

Just a quick reply from me for now, I'll get deeper into it later
as my head stops swimming (too much going on right now lol).

Before you-all branch-off too much, please understand I'm
strictly trying to use the (llvm-)gcc-4.2 family that Apple has
provided with the latest XCode/iPhone SDKs.  The only other
choice is the gcc-4.0 family in which Apple has support for all
four -arch options -- this means we can't use the gcc-3.3 family
for these builds.  (The Tiger XCode does not have full 64-bit
support.)  But since I have only a C2D iMac to use for testing
here (my PPC gear got "stolen" a while back), I can only build &
test Universal Binaries with the two Intel -arch options.

We are following Apple's Tech Note TN2137:
http://developer.apple.com/technotes/tn2005/tn2137.html
In particular:
"The --disable-dependency-tracking option to configure causes it
to not use gcc's built-in dependency generation code, which does
not work with multiple -arch targets."
I'm discovering this flag is being required for quite a lot of
projects.
(I'll only use MacPorts/Fink for clues when I'm stumped,
otherwise my builds are straight out of official src tarballs.)

Somehow since my original post on Sunday, I found
coreutils-7.0.59, which still fails building the test suite as I
reported.

I also used your git website to get snapshots of coreutils and
gnulib.  I told coreutils's bootstrap to point to my local gnulib
snapshot.  I think it worked correctly.  Still fails as reported.

Since the compiler is balking during building of the test suite,
I went ahead to install coreutils-7.0.59 anyway:

$ ls -al `which cp`
- -rwxr-xr-x 1 root admin 392176 2008-11-16 08:37 /usr/local/bin/cp

$ cp --version
cp (GNU coreutils) 7.0.59-4e38e6
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjörn Granlund, David MacKenzie, and Jim Meyering.

$ file /usr/local/bin/cp
/usr/local/bin/cp: Mach-O universal binary with 2 architectures
/usr/local/bin/cp (for architecture i386):      Mach-O executable i386
/usr/local/bin/cp (for architecture x86_64):    Mach-O 64-bit
executable x86_64

As for the missing @LIBINTL@, I believe adding -L/usr/local/lib
to LDFLAGS is letting some projects configure find it, even tho I
have specifically specified --with-lib{intl,iconv}=/usr/local
(yes both are built with the two -arch options).

As for "fixes not yet done", well, doesn't someone need to be
testing this kind of stuff before release?  ;)  See, that's my
pet peeve against using such things as MacPorts & Fink, because
they will not allow me to specify what compilers & environments
to use as a Developer needs (without tons of hacking of course;
it's just easier to manually build straight from tarballs).

Now FYI I am following the requisites (manually) to build
everything needed for the pan2 newsreader -- lots & lots of GNOME
stuff but not the full GUI system itself.  Just last night I
discovered the two current Glib2 releases have ltmain.sh scripts
that are in sad shape: I had to get libtool-2.2.6a and do the
autogen.sh to refresh things there, but still had to hack it to
report '.dylib' shared lib suffixes properly, which is probably
an indication that Glib2 configure isn't calling that function
quite right with newer libtools.  But I dunno, just an educated
guess after doing this for what 10+ years or so.  ;)  A few
projects had to fall back to using gcc-4.0 (as provided by Apple
in XCode-3.1.1 or iPhone-2.1).  So far, tho, at least we have
dual 32-&-64-bit support for the whole chain.

This is the general script/environment I'm using for these
builds:
>>>>
#
export PATH="\
/usr/local/bin\
:/usr/X11R6/bin\
:/usr/local/sbin\
:/usr/bin\
:/usr/sbin\
:/bin\
:/sbin\
:/Developer/usr/bin\
:/Developer/Tools\
"
#
export CC=llvm-gcc-4.2
export CPP=llvm-cpp-4.2
export CXX=llvm-g++-4.2
export OBJC=${CC}
export OBJCPP=${CPP}
#
export CFLAGS=" -Os  -g  -mtune=core2 -march=core2 -
force_cpusubtype_ALL  -arch i386  -arch x86_64  -isysroot
/Developer/SDKs/MacOSX10.5.sdk "
export  CXXFLAGS="${CFLAGS}"
unset  CPPFLAGS
export OBJCFLAGS="${CFLAGS}"
#
export ACLOCAL_FLAGS=" -I /usr/local/share/aclocal  -I
/usr/share/aclocal "
#
export MACOSX_DEPLOYMENT_TARGET="10.5"
export SDKROOT="/Developer/SDKs/MacOSX10.5.sdk"
#
export LDFLAGS=" -arch i386  -arch x86_64 "
#
export LIBTOOL=/usr/local/bin/libtool
export LIBTOOLIZE=/usr/local/bin/libtoolize
#
export MANPATH="\
/usr/local/share/man\
:/usr/local/man\
:/usr/X11R6/man\
:/usr/man\
:/usr/share/man\
:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/man
\
"
#
export PKG_CONFIG_PATH="\
/usr/local/lib/pkgconfig\
:/usr/local/share/pkgconfig\
:/usr/X11R6/lib/pkgconfig\
:/usr/lib/pkgconfig\
"
# ( I really need to document how to create a boottime persistent
RamDisk: )
TMP=/Volumes/RamDisk/tmp ; export TMP
TEMP=$TMP ; export TEMP
TMPDIR=$TMP ; export TMPDIR
TEMPDIR=$TMP ; export TEMPDIR
#
./configure     \
- --prefix=/usr/local   \
- --with-libiconv-prefix=/usr/local     \
- --with-libintl-prefix=/usr/local      \
- --disable-dependency-tracking \
- --disable-acl \

# ( other options as needed per project )
<<<<

Yeah this really _is_ a "quick reply", you don't wanna see one of
my "long" ones.  :D

Anyway, I got this out where it can be archived (I hope), maybe
it'll benefit someone.  Only hope hushmail doesn't botch the
text formatting or discussion threading.

I'll stay tuned.

Thank you again.


-----BEGIN PGP SIGNATURE-----
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0

wkYEARECAAYFAkkjA4kACgkQZbt5KOxKrtTqjQCgv6ivzDwoerSlfByxgme4kJDuk/oA
mwQPDTncL2gsjkgHPElUiaBtlceO
=Sw07
-----END PGP SIGNATURE-----





reply via email to

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