[MacPorts] #16648: lbdb 0.36_0 build error
MacPorts
noreply at macports.org
Thu Sep 25 06:30:46 PDT 2008
#16648: lbdb 0.36_0 build error
---------------------------------+------------------------------------------
Reporter: jrh at theptrgroup.com | Owner: macports-tickets at lists.macosforge.org
Type: defect | Status: new
Priority: Normal | Milestone: Port Bugs
Component: ports | Version: 1.6.0
Keywords: lbdb | Port: lbdb
---------------------------------+------------------------------------------
When I attempt to upgrade from 0.34_0 to 0.36_0, the build fails at the
fetchaddr step:
{{{
/usr/bin/gcc-4.0 -O2 -liconv -L/opt/local/lib fetchaddr.o rfc822.o
helpers.o rfc2047.o -o fetchaddr
Undefined symbols:
"_iconv", referenced from:
_rfc2047_decode in rfc2047.o
_rfc2047_decode in rfc2047.o
"_iconv_close", referenced from:
_rfc2047_decode in rfc2047.o
"_iconv_open", referenced from:
_rfc2047_decode in rfc2047.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [fetchaddr] Error 1
}}}
I believe this is because of the order of parameters in the fetchaddr make
target:
{{{
fetchaddr: $(srcdir)/fetchaddr.o $(srcdir)/rfc822.o $(srcdir)/helpers.o \
$(srcdir)/rfc2047.o
$(CC) $(CFLAGS) $(LIBICONV) $(LDFLAGS) $? -o $@
}}}
gcc is told to link libiconv before it sees the object files (and before
it even sees LDFLAGS to know about /opt/local/lib). That should probably
look more like:
{{{
$(CC) $(CFLAGS) -o $@ $? $(LDFLAGS) $(LIBICONV)
}}}
so that (1) it encounters symbols from libiconv before choosing what to
link from it, and (2) so that it gets the MacPorts libiconv instead of the
one in /usr/lib.
I believe that the qpto8bit rule will have the same problems:
{{{
qpto8bit: $(srcdir)/qpto8bit.o $(srcdir)/rfc822.o $(srcdir)/helpers.o \
$(srcdir)/rfc2047.o
$(CC) $(CFLAGS) $(LIBICONV) $(LDFLAGS) $? -o $@
}}}
--
Ticket URL: <http://trac.macports.org/ticket/16648>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list