On Apr 19, 2013, at 2:37 PM, Lawrence Velázquez <[email protected]> wrote:
> On Apr 19, 2013, at 4:55 PM, "Adam Dershowitz Ph.D., P.E." > <[email protected]> wrote: > >> I just tried to do an upgrade. But it fails with these errors at the end of >> the log file: >> >> :info:build /usr/bin/clang -L/opt/local/lib -arch x86_64 -arch i386 >> -fstack-protector -force_flat_namespace -o miniperl \ >> :info:build gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o >> reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o >> doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o >> perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \ >> :info:build miniperlmain.o opmini.o perlmini.o -ldl -lm -lutil -lc >> :info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for >> unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 >> 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked >> (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386 >> :info:build clang: error: linker command failed with exit code 1 (use -v to >> see invocation) > > Reported a couple of hours ago. > > https://trac.macports.org/ticket/38858 I did a search, but then didn't send my email until later, so missed it. And some of the duplicates were obviously related, until after digging into them. > >> I believe that the reason for this error is that it seems that there is a >> mismatch between standard library not being universal and perl being >> universal: >> $port installed perl5.12 libstdcxx >> The following ports are currently installed: >> libstdcxx @4.8-20130411_0 (active) >> perl5.12 @5.12.4_1+universal (active) > > Strictly speaking yes, but the final Perl installation does not seem to use > libstdc++. This particular clang invocation probably should not use > "-L/opt/local/lib". > >> What I am trying to understand is how that can happen, and why an upgrade >> would make this problem show up. I don't believe that I have explicitly >> installed anything +universal. But, I understand that certain things >> require universal, so some installs (wine-devel?), would have caused >> dependents to be reinstalled as universal. So, I do have a bunch of things >> installed as universal. >> So, I assume that I could get the upgrade of perl5.12 to work but manually >> installing libstdcxx as universal. But, it seems that will cause many >> things to then be rebuilt, since many things depend on it. >> My main question is why this would have developed if all I did was install >> ports and upgraded periodically. > > I don't think perl5.12 has been changed materially for many months. I would > guess that you simply did not have libstdcxx installed the last time you > updated it. That is possible. I didn't explicitly install either perl or libstdcxx, but each was a dependent of other things, so I am not sure of the order they were installed in. > > Unless you're building perl5.12 with a MacPorts GCC, you should be able to > work around this by force-deactivating libstdcxx for the duration of the > update. > > sudo port -f deactivate libstdcxx > sudo port upgrade perl5.12 > sudo port activate libstdcxx > That did the job. Thanks much. --Adam _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
