#42128: [NEW] Firebird 2.5 Portfile, still problem compiling -------------------------+-------------------------------- Reporter: jul_bsd@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: Firebird | -------------------------+-------------------------------- Comment (by cal@…): The problem occurs while firebird is trying to build a local copy of `icu` (at version 30.x, current is 52.1, MacPorts has 51.2) but fails, because the linker line `:info:build /opt/local/bin/g++-mp-4.9 -dynamiclib -dynamic -pipe -Os -m64 -D_THREAD_SAFE -O2 -arch x86_64 -mmacosx-version-min=10.6 -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-compatibility_version -Wl,30 -Wl,-current_version -Wl,30.0 -install_name /Library/Frameworks/Firebird.framework/Versions/A/Libraries/libicuuc.dylib -o ../lib/libicuuc.dylib.30.0 putil.o uobject.o cmemory.o umutex.o udata.o ucmndata.o udatamem.o udataswp.o umapfile.o ucol_swp.o uresbund.o ur esdata.o resbund.o ucat.o locmap.o uloc.o locid.o uhash.o uhash_us.o ucnv.o ucnv_bld.o ucnv_cb.o ucnv_cnv.o ucnv_err.o ucnv_ext.o ucnv_io.o ucnvlat1.o ucnv_u7.o ucnv_u8.o ucnv_u16.o ucnv_u32.o ucnvscsu.o ucnvbocu.o ucnvmbcs.o ucnv2022.o ucnv hz.o ucnv_lmb.o ucnvisci.o unistr.o utf_impl.o ustring.o ustrcase.o cstring.o ustrfmt.o ustrtrns.o normlzr.o unorm.o unorm_it.o chariter.o schriter.o uchriter.o uiter.o uchar.o uprops.o propname.o ubidi.o ubidiwrt.o ubidiln.o ushape.o unames .o ucln_cmn.o uscript.o usc_impl.o uvector.o ustack.o uvectr32.o ucmp8.o uarrsort.o utrie.o uset.o uniset.o ruleiter.o caniter.o unifilt.o unifunct.o usetiter.o brkiter.o brkdict.o ubrk.o dbbi.o dbbi_tbl.o rbbi.o rbbidata.o rbbinode.o rbbirb .o rbbiscan.o rbbisetb.o rbbistbl.o rbbitblb.o icuserv.o iculserv.o icunotif.o uenum.o ustrenum.o uidna.o usprep.o punycode.o cwchar.o filestrm.o umemstrm.o util.o parsepos.o utrace.o locbased.o -L../lib -L../stubdata -licudata -lpthread -lm` tries to link against its internal copy of `libicudata.dylib` using `-licudata` in `../lib`, but finds the one installed by MacPorts due to `-L/opt/local/lib` before `-L../lib` first, links against that one, which doesn't have `_icudt30_dat` but `_icudt51_dat`, which causes the link to fail: {{{ :info:build Undefined symbols for architecture x86_64: :info:build "_icudt30_dat", referenced from: :info:build _openCommonData.part.0 in udata.o :info:build ld: symbol(s) not found for architecture x86_64 :info:build collect2: error: ld returned 1 exit status }}} So, - Can Firebird be convinced to not build a private copy of icu, but rather just use the one MacPorts already has? - If not, you need to adjust LDFLAGS or the linker search path in a way that will cause the linker to find the `libicudata.dylib` in `../lib` first. I also think using GCC for C++ code is critical since 10.9, because all other C++ libs use the new `libc++` runtime library, but stuff built with GCC will use `libstdc++`. Since you can't mix those two libraries you'll not be able to use any libraries installed by this port in other ports using C++ (and I'd assume that would affect the firebird client libraries). Please file a ticket upstream to request `clang` and `libc++` compatibility. -- Ticket URL: <https://trac.macports.org/ticket/42128#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X