Re: Problem building libstdc++ for the avr target

[Vladimir V <vv.os.swe@gmail.com>]

Hello.

Recently I tried the 'freestanding' build of the libstdc++ for the avr to
verify that my fixes were sufficient for it as well.
Unfortunately, I encountered the following error:
../../../../libstdc++-v3/libsupc++/new_opa.cc: In function 'void*
__gnu_cxx::aligned_alloc(std::size_t, std::size_t)':
../../../../libstdc++-v3/libsupc++/new_opa.cc:97:28: error: 'malloc' was
not declared in this scope
   97 |   void* const malloc_ptr = malloc(sz + al);

My investigation showed that in the chain of includes the stdlib.h of the
avr-libc is not present.
It looks like includes are resolved in the following way (here are the
original paths as they are linked from out folders during build):
new_opa.cc -> libstdc++-v3/include/c_compatibility/stdlib.h ->
libstdc++-v3/include/c_global/cstdlib
In cstdlib, for non-hosted builds stdlib.h is not included.

This problem is not present if the non-hosted build is done with
'with-newlib' flag instead of 'with-avrlibc' (common workaround as the
avrlibc build was fixed only recently).
Might it be that some include order depends on the target libc? Or maybe
some implicit conditions are involved?

Could you please support me with this issue?

Thank you.




вт, 9 февр. 2021 г. в 11:54, Vladimir V <vv.os.swe@gmail.com>:

> Thank you for the review.
>
> > My best guess is that it is there because that file previously used
> > lstat and the linux lstat(2) man page (IMHO incorrectly) says that
> > <unistd.h> is needed.
>
> I got the same feeling as well.
>
>
>
> вт, 9 февр. 2021 г. в 11:48, Jonathan Wakely <jwakely@redhat.com>:
>
>> On 08/02/21 23:25 +0100, Vladimir V wrote:
>> >Thank you for the reply.
>> >
>> >>> I don't see why this file includes <unistd.h>, it doesn't *seem* to
>> >>> need it. Even if it's needed, the correct way to include it is:
>> >
>> >So it was there since the initial commit but during my quick walk through
>> >the history
>> >I didn't find what API from <unistd.h> was used.
>>
>> My best guess is that it is there because that file previously used
>> lstat and the linux lstat(2) man page (IMHO incorrectly) says that
>> <unistd.h> is needed.
>>
>> >So, in the patch I just deleted the include but as Keith suggested it can
>> >affect the client code.
>> >If the policy is:
>> >
>> >>> We routinely remove such transitive includes. Any code assuming that
>> >>> <fstream> defines the contents of <unistd.h> is wrong and should be
>> >>> fixed.
>> >
>> >then I would keep it like that.
>> >Or would it be better to update the patch to move it inside the guard?
>>
>> I will commit your patch unchanged. In practice it is unlikely to
>> affect anybody, because that header is only used when compiling
>> libstdc++ itself. I don't see any code in the Debian archives using it
>> except for GCC itself and one testcase in the Clang repo.
>>
>>
>>