Opened 14 years ago

Closed 14 years ago

#25772 closed defect (fixed)

texlive-bin build tries to link with icu port due to LDFLAGS and may fail (in icubuild)

Reported by: vinc17@… Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc:
Port: texlive-bin

Description

I get the following error when building texlive-bin @2009, Revision 3 (via "sudo port -v upgrade texlive"):

[...]
/usr/bin/g++-4.0 -pipe -O2 -arch ppc  -L/opt/local/lib -arch ppc  -o ../../bin/makeconv makeconv.o ucnvstat.o genmbcs.o gencnvex.o -L../../lib -lsicutu -L../../lib -lsicui18n -L../../lib -lsicuuc -L../../lib -L../../stubdata -lsicudata -lpthread -lm  
config.status: creating tools/makeconv/makeconv.1
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
_T_CString_stricmp_3_8
_u_errorName_3_8
_u_getDataDirectory_3_8
_u_getVersion_3_8
_uprv_isInvariantString_3_8
_uprv_free_3_8
_uprv_malloc_3_8
_u_strFromUTF32_3_8
collect2: ld returned 1 exit status
make[7]: *** [../../bin/makeconv] Error 1
make[6]: *** [all-recursive] Error 2
make[5]: *** [all-recursive] Error 2
make[4]: *** [icubuild] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [sublibs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
shell command " cd "/opt/local/var/macports/build/_Users_vinc17_software_dports_tex_texlive-bin/work/texlive-20091107-source" && /usr/bin/make -j2 all " returned error 2
Error: Target org.macports.build returned: shell command failed
Warning: the following items did not execute (for texlive-bin): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Log for texlive-bin is at: /opt/local/var/macports/logs/_Users_vinc17_software_dports_tex_texlive-bin/main.log
Error: Problem while installing texlive-bin

Any possible conflict with the icu port? (Due to bug #23464, I still have icu 4.3.1.)

Attachments (1)

main.log.bz2 (21.9 KB) - added by vinc17@… 14 years ago.
build log

Download all attachments as: .zip

Change History (10)

Changed 14 years ago by vinc17@…

Attachment: main.log.bz2 added

build log

comment:1 in reply to:  description Changed 14 years ago by vinc17@…

Replying to vinc17@…:

Any possible conflict with the icu port? (Due to bug #23464, I still have icu 4.3.1.)

I'd say that there's a risk, due to the first -L/opt/local/lib (that comes from LDFLAGS).

comment:2 Changed 14 years ago by vinc17@…

Summary: texlive-bin fails to build on Tiger (in icubuild)texlive-bin build tries to link with icu port due to LDFLAGS and may fail (in icubuild)

Indeed the error disappears if I deactivate icu first. The port (or MacPorts base) should get rid of -L/opt/local/lib and use a method that doesn't have the precedence over the possible relative lib directories (I'm thinking of LIBRARY_PATH).

comment:3 Changed 14 years ago by drkp (Dan Ports)

Status: newassigned

Interesting. I thought this problem had been fixed in texlive because it installs fine for me (and apparently others) with icu installed. Maybe the latest icu port matches the version in texlive but yours is too old.

That makes me wonder if it's still necessary for texlive to build its own icu -- at least at one point it had some non-standard patches, but maybe it doesn't anymore.

I agree that the proper solution is for base to use LIBRARY_PATH and C_INCLUDE_PATH (or similar) instead of -L and -I CFLAGS, but who knows when that'll happen.

comment:4 in reply to:  3 Changed 14 years ago by vinc17@…

Replying to dports@…:

Interesting. I thought this problem had been fixed in texlive because it installs fine for me (and apparently others) with icu installed. Maybe the latest icu port matches the version in texlive but yours is too old.

Perhaps the new icu has the same symbols as the one provided by texlive. But though in such a case, the build completes with no errors, it is still incorrect as the link isn't done against the correct icu library.

I agree that the proper solution is for base to use LIBRARY_PATH and C_INCLUDE_PATH (or similar) instead of -L and -I CFLAGS, but who knows when that'll happen.

AFAIK, -isystem is used instead of -I; this is a bit like C_INCLUDE_PATH: the -I options (e.g. those with relative directories) will have the precedence, as wanted. This also probably explains the "Undefined symbols" error I get: the library (taken from the icu port) and the header (taken from texlive) do not match.

comment:5 Changed 14 years ago by vinc17@…

Indeed in the Makefile, I can see:

CFLAGS = -pipe -O2 -arch ppc
CPPFLAGS = -isystem/opt/local/include
LDFLAGS = -L/opt/local/lib -arch ppc

and in the gcc man page, for "-isystem dir": "Search dir for header files, after all directories specified by -I but before the standard system directories."

comment:6 Changed 14 years ago by drkp (Dan Ports)

Set the paths using C_INCLUDE_PATH and LIBRARY_PATH in r70023. Does it work for you now?

comment:7 Changed 14 years ago by vinc17@…

You need to replace

configure.cppflags-delete   -L${prefix}/lib

by

configure.ldflags-delete    -L${prefix}/lib

since the -L... is in the LDFLAGS.

I'm trying the upgrade with this change...

comment:8 Changed 14 years ago by vinc17@…

With the above change, texlive-bin can be compiled and works. But since some programs are written in C++, perhaps CPLUS_INCLUDE_PATH should be used too. I didn't see any error, but it is still possible that a header file from /usr/include had been used instead of the one from /opt/local/include. An incompatibility may yield build-time or run-time failures.

Note that if you want a single environment variable, CPATH could be used (as it is language-independent), but C_INCLUDE_PATH and CPLUS_INCLUDE_PATH are more robust than CPATH, since CPATH is more like -I than -isystem. This means that CPATH would be ignored is a MacPorts version of cpp is used, as ${prefix}/include is a system directory in such a case (however, since ${prefix}/include comes first, it would still have the precedence over /usr/include, and everything should be fine).

comment:9 Changed 14 years ago by drkp (Dan Ports)

Resolution: fixed
Status: assignedclosed

r70095 sets configure.ldflags instead of cppflags, and sets CPLUS_INCLUDE_PATH in the environment. Testing with otool -L shows that nothing is being linked against /opt/local/lib/libicu*

Note: See TracTickets for help on using tickets.