BUG: Cannot build R

[yaseppochi (Stephen J. Turnbull)]

The Portfile uses gcc-3.3 to build some components and gcc-3.4 for others (the FORTRAN and C++ parts, AFAICT from the Portfile). It fails because libgcc.a for 3.3 tries to link to libgcc_s.dylib for 3.4. I've tried to force either gcc-3.3 or gcc-3.4, neither of those works properly, either. Here's what goes wrong with the vanilla Portfile no variants, Mac OS X 10.3.9 on PowerBook G4:

gcc-3.3 -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/opt/local/include -DHAVE_CONFIG_H -g -O2 -c Rmain.c -o Rmain.o gcc-3.3 -mdynamic-no-pic -L/usr/lib/gcc/darwin/3.3 -L/opt/local/lib -lgcc -o R.bin Rmain.o -L../../lib -lR ld: warning prebinding disabled because dependent library: libR.dylib is not prebound ld: warning multiple definitions of symbol _signgam ../../lib/libR.dylib(lgamma.lo) definition of _signgam /usr/lib/libSystem.dylib(gamma9.o) definition of _signgam ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _locale_charset used from dynamic library /opt/local/lib/libiconv.2.dylib(localcharset.o) not from earlier dynamic library /opt/local/lib/libintl.3.dylib(localcharset.o) ld: /usr/lib/gcc/darwin/3.3/libgcc.a(_fixunsdfdi.o) illegal reference to symbol: _floatdidf defined in indirectly referenced dynamic library /opt/local/lib/gcc-3.4/libgcc_s.1.0.dylib

[gwright@…]

Are you building the latest R (version 2.2.0)? A new portfile was checked in yesterday.

Yes, the port is built using two different compilers. This is recommended by the upstream maintainers. On OS X, R requires "-framework" options which are only present in Apple's gcc/g++. R also has pieces that require fortran. Since there is no fortran in the Apple gcc tree, we have to use a different version.

The latest portfile has been tested on Tiger and it builds and passes all tests. Please try a "sudo port selfupdate" and try again.

I agree that the situation is not good and building with compilers from two different gcc releases is prone to problems, but at the moment there's not a good solution.

I will also assign the bug ot the port maintainer. I have also reclassified the severity as "normal" ("blocker" means a bug that prevents _any_ port from building).

Best Wishes, Greg

[konis@…]

I think the Portfile needs something like

platform macosx 3 {

configure.env-delete CC=gcc-dp-3.4 CXX=g++-dp-3.4 configure.env-append CC=gcc-3.3 CXX=g++-3.3

}

platform macosx 4 {

configure.env-delete CC=gcc-dp-3.4 CXX=g++-dp-3.4 configure.env-append CC=gcc-3.3 CXX=g++-3.3 configure.env-delete LDFLAGS="-L${prefix}/lib" configure.env-append LDFLAGS="-L/usr/lib/gcc/darwin/3.3 -L${prefix}/lib -lgcc"

}

Where the 3 and the 4 correspond to the y in Mac OS X 10.y.x. Is this supported? Also (since I do not have a copy of Panther) can someone verify whether the R 2.2.0 port builds on Panther when the lines

configure.env-delete LDFLAGS="-L${prefix}/lib" configure.env-append LDFLAGS="-L/usr/lib/gcc/darwin/3.3 -L${prefix}/lib -lgcc"

are removed from the macosx variant?

[mww@…]

5. g. something like:

platform darwin 8 {

configure.env-append CC=/usr/bin/gcc-3.3 CPP=/usr/bin/cpp-3.3 CXX=/usr/bin/g++-3.3

}

should do the trick for 10.4, while 'darwin 7' corresponds to 10.3 etc. Is the LDFLAGS stuff really necessary?

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #1)

Are you building the latest R (version 2.2.0)? A new portfile was checked in yesterday.

Yes.

The latest portfile has been tested on Tiger and it builds and passes all tests.

I beg to differ. It fails the "backward compatibility" test.

Not much you can do if all the developers have upgraded already, but I'm deliberately not upgrading for exactly that reason (ie, I don't need tiger and the people in my project have upgraded, so somebody gotta do the backward tests---that's me).

Please try a "sudo port selfupdate" and try again.

Did so already, twice. No joy.

(In reply to comment #2)

can someone verify whether the R 2.2.0 port builds on Panther when the lines

configure.env-delete LDFLAGS="-L${prefix}/lib" configure.env-append LDFLAGS="-L/usr/lib/gcc/darwin/3.3 -L${prefix}/lib -lgcc"

are removed from the macosx variant?

No joy, sorry. Same error. Tried twice, with a "port clean R" in between.

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #4)

(In reply to comment #2)

can someone verify whether the R 2.2.0 port builds on Panther when the lines

configure.env-delete LDFLAGS="-L${prefix}/lib" configure.env-append LDFLAGS="-L/usr/lib/gcc/darwin/3.3 -L${prefix}/lib

-lgcc"

are removed from the macosx variant?

No joy, sorry. Same error. Tried twice, with a "port clean R" in between.

I haven't had a chance to figure out how to apply this information to R, but in trying to get XEmacs to discover and configure PostgreSQL, I got a similar error about invalid linking to indirect library -lcrypto when linking the autoconf test program with -lpq -lssl. Adding -lcrypto to the link flags got me a successful result. Maybe something similar is necessary here?

I suspect it will be kinda fragile to fix because it's internal GCC stuff and I assume that gcc-3.3's libgcc_s will also need to be linked. If I get a chance to try it and either succeed or get a new error message I'll let you know.

[konis@…]

Revised R 2.2.0 Portfile

[konis@…]

Patch file required for R 2.2.0_1

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #6)

Created an attachment (id=4708) [edit] Revised R 2.2.0 Portfile

Now builds R with the gcc 4.0 compiler. Tested locally on Panther and Tiger.

(In reply to comment #7)

Created an attachment (id=4709) [edit] Patch file required for R 2.2.0_1

Patches the configure script so that -bundle is never the first arguments to gcc.

Works for me! Thank you very much!

(Mac OS 10.3.9, DarwinPorts base updated a few minutes ago, PowerBook G4)

[gwright@…]

Hi Kjell,

I'll give it a test on my machine and check it in. Thanks!

-Greg

[gwright@…]

I committed the new portfile and an amended patch (I removed the -no-cpp-precomp option which generate spurious warning messages when used with a non-Apple gcc).

I also noticed that the build fails under gcc-4.0.0 due to a compiler bug. gcc-4.0.2 worked fine. People experiencing difficulties should first ensure that they have the latest gcc40 port.

-Greg