Re: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system

[Pedro Alves <palves at redhat dot com>]

On 09/12/2018 06:11 PM, Sergio Durigan Junior wrote:
> On Wednesday, September 12 2018, Pedro Alves wrote:
> 
>> On 09/11/2018 07:21 PM, Sergio Durigan Junior wrote:
>>> On Tuesday, September 11 2018, Pedro Alves wrote:
>>>
>>>> On 09/11/2018 01:38 AM, Sergio Durigan Junior wrote:
>>>>
>>>>> This is happening because, before the commit mentioned above,
>>>>> 'common-utils.c' (which gets transformed into 'common-utils-ipa.c'
>>>>> during the gdbserver build) wasn't calling 'stat'.  It doesn't seem like
>>>>> a regression; it seems like a hidden problem that was uncovered by the
>>>>> need of 'stat'.
>>>>>
>>>>> I don't know why this problem is manifesting only when compiling IPA,
>>>>> and not when compiling 'common-utils.c' during GDB's/gdbserver's build.
>>>>
>>>> Because the IPA doesn't link with gnulib.  And the answer to that wouldn't
>>>> be as simple as "just link it in", because the IPA objects are supposed
>>>> to be compiled with -fPIC and -fvisibility=hidden.  So we'd need a third
>>>> build of gnulib for the IPA.
>>>
>>> That explains it.  It seems strange to me that we still include the
>>> gnulib headers when compiling IPA; I confess I just assumed IPA was
>>> linking with gnulib because of this.
>>
>> In order _not_ to include the gnulib headers, that would mean that we'd
>> be OK with going back to making sure we do any necessary portability
>> autoconf/#ifdefery ourselves in all of common and gdbserver code that is
>> used by the IPA, which doesn't sound very appealing to me.  
>> I'd think it better / simpler maintenance-wise going forward, to work in the
>> direction of linking with gnulib if/when we find a need.  
>>
>> The IPA has so few dependencies by design that in practice just using the
>> headers should be fine, with gnulib ironing-out any header-only portability
>> issues.  It's quite likely that a port that can use the IPA won't really need
>> any gnu_foo replacement function.  And if it does, then it should be
>> better to use gnulib's replacements instead of duplicating what gnulib
>> already does, I'd think.
> 
> I guess I don't really understand what's going on behind the curtains
> here, then.  I thought that, since IPA doesn't link with gnulib, then we
> shouldn't be compiling it using "... -I./../gnulib/import
> -Ibuild-gnulib-gdbserver/import ...", since it can be confusing for the
> reader to determine "oh, gnulib's header files are being included, but
> the library is not actually *linking* with gnulib".  I understand that
> it'd be simpler to just build a third gnulib just for linking with IPA,
> but it seems like we're not going to do that, at least not right now.

gnulib provides:

 #1 - replacement headers for broken system headers.
 #2 - replacement implementations of system/libc functions, for broken
      systems.
 #3 - extra utility functions 

For #2, the replacement functions go by the same name as the system
function, but prefixed by "rpl_".  "#define foo rpl_foo" is used to 
provide the illusion that you're calling the original function.
If all you need are replacement headers, #1 above, e.g., because you
need a guarantee to have a C99-or-later-conforming stdint.h, and never call
any of the functions that need to be replaced (#2), or any of the extra
function (#3 above), then there's nothing of interest to link with in
the generated libgnu.a.  If we move the stat call elsewhere not used by the
IPA, then linking the IPA with gnulib would be effectively a no-op.
Until/unless someone adds some call that is resolved to some rpl_foo function
that is really necessary on some port, that is.  When/if that happens, we
must necessarily consider whether to build a gnulib for the IPA, of course.
Until then, it doesn't seem worth it to me to go through the effort in
order to link in a no-op library.

But if someone wants to give it a try, then please, by all means,
I'd definitely be happy!  It isn't impossible at all.  It just seemed
like the "get stat out of the way" solution would be quick enough
to handle, and harmless otherwise.

> 
> Anyway, this is all very unimportant and I don't want to waste people's
> time; I'm just trying to understand and to express the difficulty that I
> had while examining the logs (i.e., determining that IPA wasn't linking
> with gnulib, despite the inclusion of the headers).

It's just one of those things that you know after experiencing it
a few times.  If the linker complains about some library symbol, the
first thing to look at is whether you're actually including the library
in the link.

Thanks,
Pedro Alves