libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3

[d.schreij@…]

I have found several reports of this problem before, but those were 8 months old. I have the problem again that libstdcxx fails to build on my ML 10.8.3 installation. I have XCode 4.6.2 installed and am building everything with i386 architecture. Another (closed) ticket about this problem mentioned the issue might be caused by an outdated version of ld64. I have installed the latest version (ld64 @134.9_1+llvm33), yet the problem still occurs. I have attached the Main.log of libstdcxx build report.

[d.schreij@…]

Libstdcxx log

[Veence (Vincent)]

The culprit is here:

:info:build yes
:info:build checking for sys/types.h... yes
:info:build checking for sys/stat.h... yes
:info:build if [ x"" != x ]; then \
:info:build       /usr/bin/clang -arch i386 -c -DHAVE_CONFIG_H -pipe -O2  -I. -I../../gcc
-4.8-20130411/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-protot
ypes -pedantic   ../../gcc-4.8-20130411/libiberty/sha1.c -o pic/sha1.o; \
:info:build     else true; fi
:info:build checking for stdlib.h... /usr/bin/clang -arch i386 -c -DHAVE_CONFIG_H -pipe -
O2  -I. -I../../gcc-4.8-20130411/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-com
pat -Wstrict-prototypes -pedantic  ../../gcc-4.8-20130411/libiberty/sha1.c -o sha1.o
…

You see the -arch i386 in the clang flags? That what causes libiberty.a to be built 32bit (i386). No wonder that the link with 64bit binaries fails…

[d.schreij@…]

But I have set build_env to i386 in macports.conf. Shouldn't everything be compiled in that architecture then? Is this a mistake of mine, or due to how it is currently implemented in macports? the first time everything compiled fine at least, but after upgrade of outdated ports this problem occurred.

[Veence (Vincent)]

Hmmmm… I wonder. At any rate, building for i386 arch is wrong, since you obviously own a 64bit machine (otherwise you wouldn’t be able to run ML). So, at best, your choice cripples your binaries and,at worse, make some ports go astray.

But if you have compiled all your binaries for i386, upgrading to x86_64 means rebuilding the whole set of ports. It‘s up to you to make up your mind… Veel gluck een groeten!

[d.schreij@…]

Yeah, I know. The i386 option is somewhat of a forced choice. A critical package does not work well yet in x64 (py27-pyglet) so I'm stuck with i386 until that's fixed. I still find it peculiar that older versions of libstdcxx did manage to compile correctly in i386 and this problem only occurred with the more recent versions.

[Veence (Vincent)]

Somehow the building process must have changed, or something has been altered in the Portfile. The version 1.2 of pyglet seems to work on 64-bit machines, though?

[d.schreij@…]

Version 1.2alpha of pyglet is sadly still in Alpha state (and has been for ages, seems like it will never escape it) and still very buggy, with many unexpected crashes. I'll just wait this one out and see if it eventually will work again. Otherwise I will have to find a way around pyglet. Thanks (bedankt!) for your helpful comments, nevertheless!

[larryv (Lawrence Velázquez)]

Thanks. In the future, please Cc relevant port maintainers.

[Veence (Vincent)]

Als het U belief! Tot ziens.

[larryv (Lawrence Velázquez)]

The clang++ invocations are not respecting build_arch, which is why “the architecture being linked” is x86_64.

:info:build /usr/bin/clang++   -pipe -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -L/opt/local/lib -o build/genhooks \
:info:build 	    build/genhooks.o build/errors.o ../build-i386-apple-darwin12/libiberty/libiberty.a
:info:build ld: warning: ignoring file ../build-i386-apple-darwin12/libiberty/libiberty.a, file was built for archive which is not the architecture being linked (x86_64): ../build-i386-apple-darwin12/libiberty/libiberty.a

[larryv (Lawrence Velázquez)]

Cc Me!

[d.schreij@…]

Replying to larryv@…:

The clang++ invocations are not respecting build_arch, which is why “the architecture being linked” is x86_64.

:info:build /usr/bin/clang++   -pipe -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -L/opt/local/lib -o build/genhooks \
:info:build 	    build/genhooks.o build/errors.o ../build-i386-apple-darwin12/libiberty/libiberty.a
:info:build ld: warning: ignoring file ../build-i386-apple-darwin12/libiberty/libiberty.a, file was built for archive which is not the architecture being linked (x86_64): ../build-i386-apple-darwin12/libiberty/libiberty.a

I had that feeling. Can I pass some flags to the build command, or does this have to be solved inside macports?

[larryv (Lawrence Velázquez)]

Replying to d.schreij@…:

Yeah, I know. The i386 option is somewhat of a forced choice. A critical package does not work well yet in x64 (py27-pyglet) so I'm stuck with i386 until that's fixed.

Why can’t you just build things universal then?

[larryv (Lawrence Velázquez)]

r106510 should fix this for libstdcxx, libstdcxx-devel, gcc48, and gcc49. Please let me know if it doesn’t.

[d.schreij@…]

Works perfectly now! Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Why is [get_canonical_archflags] being appended to configure.cc but ${configure.cxx_archflags} is being appended to configure.cxx? Why aren't both configure.cc and configure.cxx getting [get_canonical_archflags] appended?

[ryandesign (Ryan Carsten Schmidt)]

Answering my own question, using [get_canonical_archflags] in configure.cxx results in a build failure:

configure: error: C++ preprocessor "/lib/cpp" fails sanity check

Checking config.log, the reason is:

clang: error: cannot use 'c++-cpp-output' output with multiple -arch options

which causes configure to try to fall back on other cpps, such as /lib/cpp, which doesn't exist.