Build Error on FreeBSD 12

John Baldwin jhb@FreeBSD.org
Sat Nov 9 00:10:00 GMT 2019


On 11/8/19 3:36 PM, Joel Sherrill wrote:
> On Fri, Nov 8, 2019 at 11:20 AM John Baldwin <jhb@freebsd.org> wrote:
> 
>> On 10/30/19 11:41 AM, Joel Sherrill wrote:
>>> Hi
>>>
>>> When building gdb 8.3 for *-rtems5 targets on FreeBSD 12, we are getting
>>> undefined errors for libiconv symbols. The messages are like this:
>>>
>>> ================================
>>>  CXXLD  gdb
>>> charset.o: In function `convert_between_encodings(char const*, char
>> const*,
>>> unsigned char const*, unsigned int,
>>> int, obstack*, transliterations)':
>>> charset.c:(.text+0x251): undefined reference to `libiconv_open'
>>> charset.c:(.text+0x2df): undefined reference to `libiconv'
>>> charset.c:(.text+0x434): undefined reference to `libiconv_close'
>>> charset.c:(.text+0x486): undefined reference to `libiconv_close'
>>> charset.o: In function `wchar_iterator::wchar_iterator(unsigned char
>>> const*, unsigned int, char const*, unsigned
>>>  int)':
>>> charset.c:(.text+0x4f9): undefined reference to `libiconv_open'
>>> ================================
>>>
>>> Q1: The compile line is shortened in the output so I can't tell what it
>> is
>>> linking command is really doing. What's the magic for having the full
>>> command lines printed?
>>>
>>> Q2: Does this sound familiar to anyone? We build fine on other OSes and
>>> apparently this
>>> doesn't happen on FreeBSD 11. Any hint is appreciated.
>>>
>>> The config.log does show it found iconv().
>>
>> Hmm, I haven't had a bare ./configure work on FreeBSD for quite some time
>> as it doesn't add the needed -L /usr/local/lib for libiconv even though
>> the configure scripts figure out that it needs -I /usr/local/include.
>> However, that was true for me on older releases, not just 12.  The FreeBSD
>> port (and my own build scripts for doing gdb work) work around this by
>> defining LDFLAGS="-L /usr/local/lib" in the environment when invoking
>> ./configure, e.g.:
>>
>> env LDFLAGS="-L /usr/local/lib" ./configure
>>
> 
> Thanks. I can try that by hand next week.
> 
> Do you think this is a bug in the gdb configure magic?
> 
> I would really prefer to fix this properly.

I do think it is a bug, per se, but I wasn't able to figure out it last time
that I looked at it.  The m4 bits for iconv are also pulled from GCC, so any
fix needs to be looped back through GCC first I think and then pulled into
GDB.

-- 
John Baldwin



More information about the Gdb mailing list