[MacPorts] #39135: Libstdcxx fails to build on OSX 10.8.3
#39135: Libstdcxx fails to build on OSX 10.8.3 -------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: build fail | Port: libstdcxx -------------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/39135> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by vince@…): 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… -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by vince@…): 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! -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by vince@…): 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? -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: Libstdcxx fails to build on OSX 10.8.3 --------------------------+-------------------------------- Reporter: d.schreij@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: build fail Port: libstdcxx | --------------------------+-------------------------------- Comment (by 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! -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 --------------------------+------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | --------------------------+------------------- Changes (by larryv@…): * cc: jeremyhu@… (added) * keywords: build fail => * owner: macports-tickets@… => mww@… Comment: Thanks. In the future, please Cc relevant port maintainers. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 --------------------------+------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | --------------------------+------------------- Comment (by vince@…): Als het U belief! Tot ziens. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 --------------------------+------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | --------------------------+------------------- Comment (by 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 }}} -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 --------------------------+------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | --------------------------+------------------- Comment (by d.schreij@…): Replying to [comment:9 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? -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 --------------------------+------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | --------------------------+------------------- Comment (by larryv@…): Replying to [comment:4 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? -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 ----------------------------------------------------+-------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: fixed | Keywords: Port: libstdcxx libstdcxx-devel gcc48 gcc49 | ----------------------------------------------------+-------------------- Changes (by larryv@…): * status: new => closed * resolution: => fixed * port: libstdcxx => libstdcxx libstdcxx-devel gcc48 gcc49 Comment: r106510 should fix this for libstdcxx, libstdcxx-devel, gcc48, and gcc49. Please let me know if it doesn’t. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 ----------------------------------------------------+-------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: fixed | Keywords: Port: libstdcxx libstdcxx-devel gcc48 gcc49 | ----------------------------------------------------+-------------------- Comment (by d.schreij@…): Works perfectly now! Thanks! -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 ----------------------------------------------------+-------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: fixed | Keywords: Port: libstdcxx libstdcxx-devel gcc48 gcc49 | ----------------------------------------------------+-------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: 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? -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X
#39135: libstdcxx @4.8-20130411_0: i386 build failure on 10.8.3 ----------------------------------------------------+-------------------- Reporter: d.schreij@… | Owner: mww@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: fixed | Keywords: Port: libstdcxx libstdcxx-devel gcc48 gcc49 | ----------------------------------------------------+-------------------- Comment (by ryandesign@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/39135#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts