p5.12-xml-parser doesn't respect build_arch

[jhkoivis@…]

I have migrated from leopard to snow leopard (osx 10.6.8) and I have a macbook 5.1. This is system that has some x86_64 features, but not all, hence I always compile for arch i386. I have checked the migration guide and my macport.conf has build_arch=i386.

if I say 'installed' in port shell I get (for p5.12-xml-parser):

p5.12-xml-parser @2.400.0_2 (active) platform='darwin 10' archs='i386'

But if I say:

lipo -info /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle /opt/local/lib/libexpat.1.dylib

I get:

Architectures in the fat file: /opt/local/lib/libexpat.1.dylib are: i386 ppc7400 

Non-fat file: /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle is architecture: x86_64

Which means that the architechture is x86_64. Now every port that is checking p5-xml-parser fails, because they run the check:

/opt/local/bin/perl5.12 -e "require XML::Parser"

Which outputs:

Can't load '/opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle' for module XML::Parser::Expat: dlopen(/opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle, 1): no suitable image found.  Did find:
        /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle: mach-o, but wrong architecture at /opt/local/lib/perl5/5.12.3/darwin-multi-2level/DynaLoader.pm line 204.
 at /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 18
Compilation failed in require at /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 18.
BEGIN failed--compilation aborted at /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 22.
Compilation failed in require at -e line 1.

To fix this I hacked my /usr/bin/gcc-4.2 to look like this:

#!/bin/sh
/usr/bin/gcc-4.2-orig -m32 "$@"

I just force 32bit mode by -m32. The original gcc-4.2 is moved to gcc-4.2-orig. This fixed my problem: lipo gives i368 and intltool is compiling (requires p5-xml-parser).

I think in some point p5.12-xml-parser does not add -m32 flag even if its supposed to do that. I would like to contribute by fixing this if you give me a nudge where to start. I am noob to macports but not with collaboration and programming.

[ryandesign (Ryan Carsten Schmidt)]

The main perl ports were recently fixed to no longer include -arch flags in their installed files. See #24779. I would guess this is responsible for p5.12-xml-parser and perhaps (all?) other p5 ports not using -arch flags. If this indeed affects many (all?) p5 ports then the perl5 portgroup would be the right place to fix this. Probably adding [get_canonical_archflags] to CFLAGS/CPPFLAGS/LDFLAGS, or to CC/CXX, would be the fix.

I do not however understand why you want to build for i386 on a machine that is fully capable of running 64-bit software. The only thing some early 64-bit Macs couldn't do was boot to the 64-bit kernel, however this has no bearing whatsoever on your ability to run 64-bit userspace software. Running 64-bit Intel software should be faster than running 32-bit Intel software because 64-bit Intel software has access to more registers.

[pjue2009@…]

How did you modify gcc? I think I have a ​similar issue.

[pjue2009@…]

Cc Me!

[jhkoivis@…]

I have the following hacks:

1. I make copy the compiler to /usr/bin/gcc-4.2-orig
2. overwrite the gcc-4.2 with a script (or create a new file and and

overwirte with a link)

Below are the scripts (-m32 forces 32bit) and a listing of my /usr/bin/. If you have the same system/problem you want to do the same thing for g++ compiler. It will fail for the same reason for some other port... (I think one dependency for texlive?)

less /usr/bin/gcc-4.2

#!/bin/sh
/usr/bin/gcc-4.2-orig -m32 "$@"

less /usr/bin/g++-4.2

#!/bin/sh
/usr/bin/g++-4.2-orig -m32 "$@"

listing:

-rwxr-xr-x  1 root  wheel    42B 22 Hel 10:08 /usr/bin/g++-4.2
-rwxr-xr-x  1 root  wheel   162K 22 Hel 09:59 /usr/bin/g++-4.2-orig
lrwxr-xr-x  1 root  wheel    20B 15 Hel 16:10 /usr/bin/gcc-4.2 -> /usr/bin/gcc-4.2-m32
-rwxr-xr-x  1 root  wheel    42B  7 Jou  2010 /usr/bin/gcc-4.2-m32
-rwxr-xr-x  1 root  wheel   162K 26 Hei  2010 /usr/bin/gcc-4.2-orig

Below is a link to stackoverflow with the same question:

​http://stackoverflow.com/questions/4369765/how-to-force-usr-bin-gcc-usr-bin-gcc-m32

[hackdefendr (HackDefendr)]

The question I have...what good does that hack do if the build fails during the configure phase, and never makes it to the compile phase where gcc/g++ would get used?

[jhkoivis@…]

Good point, its actually one of the dependencies that does not respect the build arch (expat.bundle?). I don't remember exactly whether I uninstalled all perl related stuff before the hack and re-installed after the hack...

Basically, one port in the p5.12-xml-parser dependency tree does not respect build arch, and compiling the whole tree with this hack takes care of the problem. There might be an easier fix, this is like fixing electronics with a hammer...

[hackdefendr (HackDefendr)]

It seems that what I ended up doing was to add the below configure appends (compiler, cflags, ldflags, cxxflags) to the Portfiles of perl5.12, perl5, p5.12-xml-parser and to intltool and build.

configure.compiler  gcc-4.2
configure.cflags-append -m32
configure.ldflags-append -m32
configure.cxxflags-append   -m32

But even after adding those lines to the perl5.12 p5.12-xml-parser Portfile...the output from perl -e "require XML::Parser" still bombed:

# /opt/local/bin/perl5.12.3 -e "require XML::Parser"
Can't load '/opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle' for module XML::Parser::Expat: dlopen(/opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle, 1): no suitable image found.  Did find:
	/opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/auto/XML/Parser/Expat/Expat.bundle: mach-o, but wrong architecture at /opt/local/lib/perl5/5.12.3/darwin-multi-2level/DynaLoader.pm line 204.
 at /opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 18.
Compilation failed in require at /opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 18.
BEGIN failed--compilation aborted at /opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level/XML/Parser.pm line 22.
Compilation failed in require at -e line 1.

I will keep playing around with variations to see if I get any better results...at least until a more season developer can join in the fun and show me where I went wrong.

[hackdefendr (HackDefendr)]

Wow!

First I noticed that some files are not removed during uninstall...thus I had to force delete the /opt/local/lib/perl5 folder.

Then, I had to go all the way back to python27, including any dependencies, and the dependencies of those dependencies to make this work. Dependencies are (not in order): ncurses, libedit, gdbm, gettext, readline, sqlite3, libiconv, xz, expat. Adding the following os.arch if statement to each and rebuilding.

if { ${os.arch}=="i386" } {
     configure.compiler  gcc-4.2
     configure.cflags-append -m32
     configure.ldflags-append -m32
     configure.optflags-append   -m32
    } else {
     configure.compiler  gcc-4.2
     configure.cflags-append -m64
     configure.ldflags-append -m64
     configure.optflags-append   -m64
}

I couldn't figure out how to force -arch flag from being used, but it didn't seem to matter because I think it was ignored anyway. I ran the perl -e command and did not receive an error...so it appears to have worked.

root /opt/local # /opt/local/bin/perl5.12 -E "require XML::Parser"                                                                                                                
root /opt/local #

And installing intltool (which pulls in xz, glib2, and pkgconfig) just for completeness and here is the results from that:

--->  Activating intltool @0.50.2_0
--->  Cleaning intltool
--->  Removing work directory for intltool

root /opt/local # port installed | grep intltool                                                                                                                                  
  intltool @0.50.2_0 (active)

Question is, how can this be simplified so that Macports will do this without reinventing the wheel.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jhkoivis@…:

Good point, its actually one of the dependencies that does not respect the build arch (expat.bundle?). I don't remember exactly whether I uninstalled all perl related stuff before the hack and re-installed after the hack...

Basically, one port in the p5.12-xml-parser dependency tree does not respect build arch, and compiling the whole tree with this hack takes care of the problem. There might be an easier fix, this is like fixing electronics with a hammer...

Expat.bundle is part of the p5-xml-parser port.

I suspect that all p5 ports are not using -arch flags, following the changes in #24779, as I said above (but I cannot verify this in a clean prefix due to other problems; see #33647; if anyone can explain that please let me know). So we need to fix the perl5 portgroup to do this.

gvibe06, I think you misunderstand the purpose of ​${os.arch}. Anyway we don't need to inspect that; we should just be able to use [get_canonical_archflags] as I said above.

[hackdefendr (HackDefendr)]

No argument on the part of me misunderstanding the ${os.arch} ... I was just trying to figure any way around the failed compile, no matter how dirty it was. If the [get_canonical_archflags] will accomplish the same thing, then I am all for it.

[jeremyhu (Jeremy Huddleston Sequoia)]

r91376

[ryandesign (Ryan Carsten Schmidt)]

I believe all p5 ports are affected and we need to fix the perl5 portgroup and not individual ports.

[jeremyhu (Jeremy Huddleston Sequoia)]

Well this particular port is not fixable by the portgroup because it is dropping the flags which would be passed in by the portgroup.

[ryandesign (Ryan Carsten Schmidt)]

Oh I see. Well I'm still confused why I'm experiencing #33647 but I guess this particular ticket is indeed fixed then.