[MacPorts] #42128: [NEW] Firebird 2.5 Portfile, still problem compiling

[MacPorts]

#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