Perl upgrade issue

Adam Dershowitz Ph.D., P.E. dersh at
Fri Apr 19 15:08:36 PDT 2013

On Apr 19, 2013, at 2:37 PM, Lawrence Velázquez <larryv at> wrote:

> On Apr 19, 2013, at 4:55 PM, "Adam Dershowitz Ph.D., P.E." <dersh at> 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.

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.


More information about the macports-users mailing list