gcc44, gcc45 on snow leopard: can't open file: ./libgcc_s.1.dylib.tmp: No such file or directory

[andrius.laikina@…]

gcc45 @4.5-20090820 fails to build on snow leopard (10A432) with message:

--->  Extracting gcc45
--->  Configuring gcc45
--->  Building gcc45
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build" && /usr/bin/make -j2 bootstrap " returned error 2
Command output: 	  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/./gcc/ -B/opt/local/i386-apple-darwin10.0.0/bin/ -B/opt/local/i386-apple-darwin10.0.0/lib/ -isystem /opt/local/i386-apple-darwin10.0.0/include -isystem /opt/local/i386-apple-darwin10.0.0/sys-include    -m64 -O2 -O2  -m64 -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I../../../gcc-4.5-20090820/libgcc -I../../../gcc-4.5-20090820/libgcc/. -I../../../gcc-4.5-20090820/libgcc/../gcc -I../../../gcc-4.5-20090820/libgcc/../include  -DHAVE_CC_TLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c		\
	     -o eh_dummy.o;				\
	  objects=eh_dummy.o;				\
	fi;							\
	/usr/bin/ar  rc libgcc_eh.a $objects
/usr/bin/ranlib: file: libgcc.a(_trampoline.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_ctors.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_powitf2.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_multc3.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_divtc3.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_fixtfdi.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_fixunstfdi.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_floatditf.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_floatunditf.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_fixtfti.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_fixunstfti.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_floattitf.o) has no symbols
/usr/bin/ranlib: file: libgcc.a(_floatuntitf.o) has no symbols
ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols
/usr/bin/ranlib -c libgcc_eh.a
/usr/bin/strip -o libgcc_s.10.4.dylib_T \
	  -s ../../../gcc-4.5-20090820/libgcc/../gcc/config/i386/darwin-libgcc.10.4.ver -c -u \
	  ./libgcc_s.1.dylib.tmp
/usr/bin/ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols
/usr/bin/strip: can't open file: ./libgcc_s.1.dylib.tmp (No such file or directory)
make[3]: *** [libgcc_s.10.4.dylib] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2

Error: Status 1 encountered during processing.

[andrius.laikina@…]

Cc Me!

[toby@…]

Please attach a build log with debugging enabled.

[andrius.laikina@…]

Log file size 1.1 MB, should I just write the log here?

[blb@…]

Replying to andrius.laikina@…:

Log file size 1.1 MB, should I just write the log here?

Using the 'Attach file' button would be best.

[andrius.laikina@…]

Replying to blb@…:

Replying to andrius.laikina@…:

Log file size 1.1 MB, should I just write the log here?

Using the 'Attach file' button would be best.

Yes, but: "File (size limit 1 MB)"

[ram@…]

Replying to andrius.laikina@…:

Yes, but: "File (size limit 1 MB)"

Can't you compress it?

[andrius.laikina@…]

clean install, debug enabled

[macports@…]

Cc Me!

[eric.nodwell@…]

gcc44 similarly fails on Snow Leopard. Build log attached (gcc44.log). Command was 'sudo port -d install gcc44 -universal buildmakejobs=1'.

It appears that the 'strip' command that fails is attempting to open './libgcc_s.1.dylib.tmp'. However, the preceeding compiler commands output to 'x86_64/libgcc_s.1.dylib.tmp'.

[ram@…]

Cc Me!

[luis.beca@…]

Cc Me!

[macports@…]

Cc Me!

[thomas.mccullough@…]

Cc Me!

[me@…]

Cc Me!

[samuel.hornus@…]

Cc Me!

[tianyicui@…]

Cc Me!

[alexandre.hamez@…]

Cc Me!

[nthomas@…]

Cc Me!

[tamyrvoll@…]

Cc Me!

[rcastain@…]

Cc Me!

[rcastain@…]

FWIW: I'm seeing similar error messages from a handful of other port builds as well. I won't pollute this ticket with them, but just wanted to note that there seems to be a more systemic related issue with similar symptoms.

[ewal@…]

Cc Me!

[ralph.ganszky@…]

The problem for this error is in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/gcc-4.4.1/libgcc/config/t-slibgcc-darwin. In line 52 is the strip command which is unnecessary because the preceding for loop do the job. In line 67 is a cp command which is also unnecessary because of a following for loop. When this two entries are gone, the first stage succeed, but the second stage compiles all in 32bit mode instead of 64bit on my hardware. After that all libraries created first does not fit.

[howarth@…]

The first thing I would try is start passing the correct triplets to configure. In my gcc4x packages on fink, I always passed...

 darwinvers=`uname -r|cut -f1 -d.`
 if [ "%m" = "powerpc" ]; then
  ../gcc-%v/configure %c --build=%m-apple-darwin${darwinvers} --host=%m-apple-darwin${darwinvers} --target=%m-apple-darwin${darwinvers}
 elif [ "%m" = "i386" ]; then
  ../gcc-%v/configure %c --with-arch=nocona --with-tune=generic --build=i686-apple-darwin${darwinvers} --host=i686-apple-darwin${darwinvers} --target=i686-apple-darwin${darwinvers}
 elif [ "%m" = "x86_64" ]; then
  ../gcc-%v/configure %c --build=x86_64-apple-darwin${darwinvers} --host=x86_64-apple-darwin${darwinvers} --target=x86_64-apple-darwin${darwinvers}
 fi

I would suspect the build system is getting really confused cause config.log shows it thinks its building a 32-bit compiler....

checking build system type... i386-apple-darwin10.0.0
checking host system type... i386-apple-darwin10.0.0
checking target system type... i386-apple-darwin10.0.0

but you are forcing 64-bit code generation in the CFLAGS, CXXFLAGS and FFLAGS. If you read....

 https://savannah.gnu.org/patch/?6827

and comment 28 from....

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180#c28

You will see this approach is wrong.

[ryandesign@…]

Replying to howarth@…:

You will see this approach is wrong.

Is there perhaps a change here that should be made to MacPorts base as opposed to individual ports?

[howarth@…]

Note also that you are kinda doing the inverse of the mistake discussed at the bottom of comment 28 in  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180#c28. In that case, Mike Stump had proposed using a patch from Apple's gcc branch that forced -m32 onto the compiler even if the triplet got reported as x86_64-apple-darwin*. You are doing the reverse of letting it pickup the incorrectly reported triplet of i386-apple-darwin10 and then force it to compile -m32 which stand the logic of the multilib build on its head. That is could well be the actual error. Also, if you don't want to pass the triplet, you can always use my proposed config.guess change that is being evaluated upstream. This change causes the default compiler to report...

[Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.2
[Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.alternative2
x86_64-apple-darwin10.0.0

and the depreciated gcc-4.0 compiler...

[Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.0
[Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.alternative2
i386-apple-darwin10.0.0

Note if you pass -m32 to gcc-4.2 you get...

[Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.2 -m32"
[Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.alternative2
i386-apple-darwin10.0.0

and if you pass -m64 to gcc-4.0 you get....

[Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.0 -m64"
[Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.alternative2
x86_64-apple-darwin10.0.0

So again. Stop forcing -m64 or -m32 onto the build. That is very bad approach. Instead, either deduce the actual code generation in the Portfile and explicitly pass the correct triplets to configure or alternatively patch config.guess so that it reports the default code generation of the system compiler being uses. I would recommend patching config.guess myself.

ps I'll make a patch for config.guess and attach to the ticket.

[howarth@…]

A general fix is a more difficult question. The approach fink has taken is to detect the architecture of code being executed with "sysctl -n hw.cpu64bit_capable" and settng their %m variable to x86_64 in that case. I have patch that Ben Elliston who maintains config.guess is evaluating. You could in theory patch the config,guess in these programs in the same manner. I will add the patch shortly.

[howarth@…]

patch to fix  https://savannah.gnu.org/patch/?6827

[howarth@…]

Let me explain that patch a bit. The operative decider on what should reported from config.guess is either the default code execution in the absence of a compiler (the second half of the patch) or better yet the *default* code generation of the system compiler as defined by CC. This is why the proposed patch doesn't break i386 fink on 10.6. Fink resorts to compiler wrappers in i386 fink which effectively passed -m32 in the definition of CC. This means that the patched config.guess in that case will always report i386-apple-darwin10 on i386 fink on 10.6. In your case, you don't need the compiler wrappers if you correct config.guess to properly deduce the native code generation.

[ryandesign@…]

Replying to howarth@…:

The approach fink has taken is to detect the architecture of code being executed with "sysctl -n hw.cpu64bit_capable" and settng their %m variable to x86_64 in that case.

That is exactly how MacPorts base determines how to set its build_arch variable.

[howarth@…]

Okay but you aren't passing the triplets so the compiler infrastructure thinks it is building a 32-bit compiler (because it would never think to look for someone passing -m64 to the CFLAGS...very bad) and the multilib is probably confused beyond belief.

[ryandesign@…]

I have no idea. Cc'ing Joshua who committed r54512 which added the code in question.

[howarth@…]

As for other macports packages, NEVER decouple code generation of the compiler from the triplet that configure detects. You might run into some hardcoded assembly language that will be compiled at the wrong architecture.

I'll try a local build with the -m64's removed and with the config.guess patch.

[jmr@…]

I made it pretty clear in the commit message that I had no idea what I was doing, it just fixed the 64-bit build on Leopard.

[howarth@…]

I am having trouble building this in my user account ports directory. When I to build a local copy, I get...

DEBUG: setting option extract.args to /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2
DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work" && /usr/bin/bzip2 -dc /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 | /usr/bin/gnutar --no-same-owner -xf -'
DEBUG: Executing org.macports.patch (gcc44)
--->  Applying patches to gcc44
Error: Target org.macports.patch returned: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory
DEBUG: Backtrace: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory
    while executing
"_cd [option worksrcpath]"
    (procedure "portpatch::patch_main" line 24)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for gcc44): org.macports.activate org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

whereas I see...

[Macintosh-2:~/ports] howarth% ls /opt/local/var/macports/build/
_Users_howarth_ports_lang_gcc44							_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_lesstif

[ryandesign@…]

Replying to howarth@…:

As for other macports packages, NEVER decouple code generation of the compiler from the triplet that configure detects.

You might want to start a thread about this on the macports-dev mailing list and explain a bit more what this means and how to accomplish this, as other port maintainers are unlikely to see your advice in this ticket.

P.S: Please remember WikiFormatting; I've fixed this in your prior comments in this ticket.

[howarth@…]

Okay...first I trying to figure out why this thing doesn't want to build in my local ports directory.

[howarth@…]

Okay, my build is still going but the attache Portfile-config_guess.diff and the associated gcc44-config.guess.diff patch eliminates the broken multilib build.

[howarth@…]

FYI, tomorrow I'll test adding in the patch I used in the gcc4x packages to provide the --disable-libjava-multilib. Redhat came up with that patch but it never made it into gcc trunk yet. There really isn't any reason to build the multilib for java since no one would ever want to use it. That will shave a significant chunk of time off of the build and cut down the size of the package.

[howarth@…]

Doh...

/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./prev-gcc/xgcc -B/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./prev-gcc/ -B/opt/local/x86_64-apple-darwin10.0.0/bin/  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1plus-dummy \
	      cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o i386-c.o darwin-c.o c-pretty-print.o c-opts.o c-pch.o incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o dummy-checksum.o main.o  libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -L/opt/local/lib -L/opt/local/lib -lmpfr -lgmp
ld: duplicate symbol _init_inline_once in libbackend.a(tree-inline.o) and tree-inline.o
collect2: ld returned 1 exit status
make[3]: *** [cc1plus-dummy] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gfortran.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2

your are missing the patch I commited to gcc trunk and 4.4 branch...

 http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/cp/ChangeLog?r1=151555&r2=151554&pathrev=151555
 http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/cp/Make-lang.in?r1=151555&r2=151554&pathrev=151555

[howarth@…]

patch to avoid darwin10 linker bug PR41180 from gcc 4.4 branch

[howarth@…]

patch to add --disable-multilib-libjava to shorten the build

[howarth@…]

add remaining patches, use --disable-multilib-libjava and re-enable multilib on ppc

[howarth@…]

With --disable-libjava-multilib available in configure, there is no reason not to build the multilib on powerpc since it shortens the build so much.

[howarth@…]

If anyone else wants to try this against the current Portfile, use...

Portfile_final.diff

and add the patches below to the files subdirectory...

gcc44-config.guess.diff
gcc44-PR41180.diff
gcc44-disable-libjava.diff

[howarth@…]

If anyone wants to test this on darwin9, the Portfile_optimized.diff adds...

if {[info exists build_arch] && ${os.platform} == "darwin"} {
    if {(${os.arch} == "i386" && $build_arch == "i386") {
        configure.post_args --with-arch=nocona --with-tune=generic --build=i686-apple-darwin${os.major} --host=686-apple-darwin${os.major} --target=i686-apple-darwin${os.major}
    }
}

which should provide the proper triplets/arch/tune settings for 32-bit Intel darwin. These what Mike Stump recommended.

[howarth@…]

Hmm...why is this Portfile missing a revision? I'll revert the bump I did on the epoch and add one.

[howarth@…]

Okay, Portfile_final.diff builds and installs on x86_64-apple-darwin10.

[Macintosh-2:~] howarth% gcc-mp-4.4 -v
Using built-in specs.
Target: x86_64-apple-darwin10.0.0
Configured with: ../gcc-4.4.1/configure --prefix=/opt/local --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --disable-libjava-multilib
Thread model: posix
gcc version 4.4.1 (GCC) 

I'll test the Portfile_optimized.diff now.

[howarth@…]

correct syntax in Portfile

[ram@…]

Replying to howarth@…:

Okay, Portfile_final.diff builds and installs on x86_64-apple-darwin10

Same here.

[howarth@…]

Thanks. Now if someone could test Portfile_optimized.diff on intel darwin9 to make sure the configure arguments...

--with-arch=nocona --with-tune=generic --build=i686-apple-darwin${os.major} --host=i686-apple-darwin${os.major} --target=i686-apple-darwin${os.major}

get passed properly in that case. I would strongly suggest using that version as you will gain something a significant speed boost in that case. The Portfile_optimized.diff builds fine on x86_64-apple-darwin10.

[howarth@…]

Hmmm. What do you pass to port so that it leaves behind the build directories so that we can run a "make -k check" with dejagnu installed? I'm sure its fine but it would be nice to know how to do that in MacPorts.

[blb@…]

On 10.5.8 Intel, Xcode 3.1.4, configure stage says:

DEBUG: Executing org.macports.configure (gcc44)
DEBUG: Environment: CPATH='/mp/include' CXXFLAGS='-pipe -O2' CPPFLAGS='-I/mp/include' CFLAGS='-pipe -O2' AS_FOR_TARGET='/usr/bin/as' LIBRARY_PATH='/mp/lib' MACOSX_DEPLOYMENT_TARGET='10.5' CXX='/usr/bin/g++-4.0' F90FLAGS='-pipe -O2 -m32' LD_FOR_TARGET='/usr/bin/ld' RANLIB_FOR_TARGET='/usr/bin/ranlib' LDFLAGS='-L/mp/lib' CFLAGS_FOR_BUILD='-O2' OBJDUMP_FOR_TARGET='/usr/bin/objdump' FCFLAGS='-pipe -O2 -m32' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' AR_FOR_TARGET='/usr/bin/ar' NM_FOR_TARGET='/usr/bin/nm' FFLAGS='-pipe -O2 -m32' OBJCFLAGS='-pipe -O2' STRIP_FOR_TARGET='/usr/bin/strip' CC='/usr/bin/gcc-4.0'
DEBUG: Assembled command: 'cd "/mp/var/macports/build/_Users_blb_devel_macports_trunk_dports_lang_gcc44/work/build" && ../gcc-4.4.1/configure --prefix=/mp --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/mp/lib/gcc44 --includedir=/mp/include/gcc44 --infodir=/mp/share/info --mandir=/mp/share/man --with-local-prefix=/mp --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/mp/include/gcc44/c++/ --with-gmp=/mp --with-mpfr=/mp --disable-libjava-multilib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9'

so looks like the args are as expected (didn't do an actual build though).

For testing, you can either define  a test phase or simply run a phase before install like sudo port build which will leave the results up to that phase in the work dir.

[alejandro.aragon@…]

Cc Me!

[allen.r.labryer@…]

Cc Me!

[trevor.bain@…]

Cc Me!

[ndoc2@…]

I must confess I'm very puzzled which version of the Portfile these patches are supposed to applied to. If I start with the one listed on the MacPorts packages listing, then neither Portfile-config_guess-fix.diff or Portfile_final.diff works completely, complaining about rejected hunks.

This seems to be the same as the version one gets when installing MacPorts and then doing a selfupdate and sync.

Can someone clarify which to start with and the sequence to use. I'm trying to get it working on an Intel running Snow Leopard.

thanks,
Peter

[ryandesign@…]

Peter, I was able to install gcc43 @4.3.4_0, gcc44 @4.4.1_0, and gcc45 @4.5-20090910_0 on Snow Leopard without modifying the ports. There were a few fixes a month ago (r57658, r57794, r57807) that seem to have helped. Have you tried to just install the ports as is, and if so, what error do you get?

[ndoc2@…]

Yes, starting from a clean install, I can now install gcc44 and octave. Thanks.

[snc@…]

Cc Me!

[ram@…]

I can no longer reproduce this issue, anyone still having problems with this?

[snc@…]

I was able to build gcc44 today.