#16648 closed defect (fixed)
lbdb 0.36_0 build error
Reported by: | jrhope | Owned by: | reilles@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.6.0 |
Keywords: | lbdb | Cc: | erwan@…, paul.t.hinze@…, blb@… |
Port: | lbdb |
Description
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 $@
Attachments (1)
Change History (10)
comment:1 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | reilles@… removed |
---|---|
Owner: | changed from macports-tickets@… to reilles@… |
comment:2 Changed 16 years ago by erwan@…
Cc: | erwan@… added |
---|
comment:3 Changed 16 years ago by erwan@…
The problem is not in the order : using $(CC) $(CFLAGS) -o $@ $? $(LDFLAGS) $(LIBICONV)
still leads to the same error
comment:5 Changed 16 years ago by paul.t.hinze@…
I hit this error as well. Grabbed 0.34 from the repository and that's working fine.
comment:6 Changed 16 years ago by blb@…
We appear to have several tickets with iconv vs. libiconv issues like this, see #13055 for example.
comment:7 Changed 16 years ago by blb@…
Cc: | blb@… added |
---|
The problem is that CPPFLAGS (which includes -I${prefix}/include
) is not being used in the Makefile. Attaching a patch which also adds the -I
to CFLAGS and fixes the problem here.
comment:8 Changed 16 years ago by blb@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in r42894 (maintainer timeout).
Cc Me!