[MacPorts] #24194: gcc42, gcc43, gcc44 won't compile with non-default build_arch

[MacPorts]

#24194: gcc42, gcc43, gcc44 won't compile with non-default build_arch
-------------------------------+--------------------------------------------
 Reporter:  gvibe06@…          |       Owner:  mww@…            
     Type:  defect             |      Status:  new              
 Priority:  Normal             |   Milestone:                   
Component:  ports              |     Version:  1.8.2            
 Keywords:                     |        Port:  gcc44 gcc43 gcc42
-------------------------------+--------------------------------------------

Comment(by roumbaba@…):

 Hi guys, I do have the exact same problem when trying to compile gcc44 and
 gcc45 when forcing build_arch i386 in macports.conf.

 I started from scracth, removing all installed ports, cleaning, removing
 macport and erasing all folder related to macports.
 I reinstalled macports to 1.9.1
 on
 os x 10.6.4
 2.66ghz intel Core 2 Duo

 I get the following error:
 sudo port install gcc44
 ...
 info:configure checking for correct version of mpfr.h no
 :info:configure configure: error: Building GCC requires GMP 4.1+ and MPFR
 2.3.2+
 ...

 but the mpfr version successfully installed by port is 3.0.0_p3 !!!


 everything is compiled in 32 bits version:
 lipo -info /opt/local/lib/lib{gmp,mpfr}.dylib
 Non-fat file: /opt/local/lib/libgmp.dylib is architecture: i386
 Non-fat file: /opt/local/lib/libmpfr.dylib is architecture: i386

 I need to have everything compiled in 32 bits version because I will be
 linking some libraries installed by port against third part SDKs and
 libraries that are 32 bits only (I do not have the source). For instance I
 will need to link 32 bits libraries  against fftw3 which will need to be
 32 bits as well.

 I am no expert but I have noticed the following macro in mpfr.h
 #define MPFR_VERSION_NUM(a,b,c) (((a) << 16L) | ((b) << 8) | (c))
 could it be that this is somewhat a problem and would return a wrong
 MPFR_VERSIOn_NUMBER if it makes wrong wordlength assumption in the i386
 case?

 could it just be that the i386 macro is wrong in it's shifts? assuming a
 wrong wordlength? So when configure asks the check the version, the number
 return is too low?

 Thanks,
 baba
 Since this ticket hasn't been active for  a long time, shall I open a new
 ticket?

-- 
Ticket URL: <http://trac.macports.org/ticket/24194#comment:16>
MacPorts <http://www.macports.org/>
Ports system for Mac OS