Restore simple LIB_SPEC using just -lc

Restore simple LIB_SPEC using just -lc

The compiler configuration is not the place to encode internal details of
the libc implementation.  When the libc implementation wants the default
link to include multiple constituent libraries, it can do that by providing
a linker script for libc.so or libc.a and let the compiler just use -lc
as it has always done.

This follows a change to the nacl newlib build to provide a libc.a linker
script.  Future changes to the libc implementation internals will not
require any gcc change.

This also removes the truly evil magical treatment of -lnosys as a special
command line option.  It's just a library like any other.

BUG=cleanup
TEST=local builds still link the same using newlib's new libc.a linker script

R=khim@google.com,pasko@google.com,eaeltsin@google.com

Committed: http://git.chromium.org/gitweb?p=native_client/nacl-gcc.git;a=commit;h=818dbb2

[khim, 2011-06-08 19:32:29]

One nit.

http://codereview.chromium.org/6995084/diff/1/gcc/gcc.c
File gcc/gcc.c (left):

http://codereview.chromium.org/6995084/diff/1/gcc/gcc.c#oldcode6809
gcc/gcc.c:6809: if (strcmp(input_filename, "-lnosys") == 0)
If you want to remove this logic then libnosys.a should also be a script.

Newlib includes some wrappers for libnosys-provided stubs and without converting
libnosys.a to linker script these wrappers can not be used with just "-lnosys".

"-lpthread -lc -lnosys -lcrt_platfor" works but this encodes "internal details
of the libc implementation" in the app build script which IMNSHO is even worse
then when this logic is embedded in a compiler configuration.

[khimg, 2011-06-08 19:36:50]

BTW even if the libnosys.a will be a script complex cases will fail. I mean
cases where not a program itself but some library employed by a program
requires -lnosys. Before this change -lnosys was automatically moved to
proper place, after it it'll be included before -lmyownlib so linking will
fail.

Are we sure naclports are compatible with this change?

On Wed, Jun 8, 2011 at 11:32 PM, <khim@chromium.org> wrote:

> One nit.
>
>
> http://codereview.chromium.org/6995084/diff/1/gcc/gcc.c
> File gcc/gcc.c (left):
>
> http://codereview.chromium.org/6995084/diff/1/gcc/gcc.c#oldcode6809
> gcc/gcc.c:6809: if (strcmp(input_filename, "-lnosys") == 0)
> If you want to remove this logic then libnosys.a should also be a
> script.
>
> Newlib includes some wrappers for libnosys-provided stubs and without
> converting libnosys.a to linker script these wrappers can not be used
> with just "-lnosys".
>
> "-lpthread -lc -lnosys -lcrt_platfor" works but this encodes "internal
> details of the libc implementation" in the app build script which IMNSHO
> is even worse then when this logic is embedded in a compiler
> configuration.
>
>
> http://codereview.chromium.org/6995084/
>

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Roland McGrath, 2011-06-08 19:48:50]

The -lnosys magic handling was too clever by half.

The libraries that go into newlib's -lc should not have any dangling undefined
references.  If they do, we should just remove the dependent functions from our
newlib build too.

An application should always put -lnosys last among their own -l switches.  Then
references from some other -lfoo will be just fine.

I don't know how to find/build/test naclports, but I can try.
If anything in there is using -lnosys and failing to put it last among libraries
specified in a link, that should just be fixed there.

[robertm, 2011-06-08 20:45:03]

BTW: We recently went through the exercise of eliminating those functions from
pnacl's newlib branch. The CL was
http://codereview.chromium.org/6929022/

On 2011/06/08 19:48:50, Roland McGrath wrote:
> The -lnosys magic handling was too clever by half.
> 
> The libraries that go into newlib's -lc should not have any dangling undefined
> references.  If they do, we should just remove the dependent functions from
our
> newlib build too.
> 
> An application should always put -lnosys last among their own -l switches. 
Then
> references from some other -lfoo will be just fine.
> 
> I don't know how to find/build/test naclports, but I can try.
> If anything in there is using -lnosys and failing to put it last among
libraries
> specified in a link, that should just be fixed there.

[khimg, 2011-06-08 21:15:44]

On Wed, Jun 8, 2011 at 11:48 PM, <mcgrathr@chromium.org> wrote:

> The -lnosys magic handling was too clever by half.
>
> The libraries that go into newlib's -lc should not have any dangling
> undefined
> references.  If they do, we should just remove the dependent functions from
> our
> newlib build too.
>
> And move them to libnosys? This will work too, I think. There are sizable
amount of functionality built around missing functions (things like
signals). It all can not be used with nacl but since usually it's exception
handling of some sort it worked fine when linked with -lnosys.


> An application should always put -lnosys last among their own -l switches.
>  Then
> references from some other -lfoo will be just fine.
>
> I'm not even sure things like lidstdc++ and/or libfortran can be fully
implemented without -lnosys.


> I don't know how to find/build/test naclports, but I can try.
> If anything in there is using -lnosys and failing to put it last among
> libraries
> specified in a link, that should just be fixed there.
>
> What will it buy us?

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Use chromium.org instead, 2011-06-08 21:32:58]

On Wed, Jun 8, 2011 at 2:15 PM, Victor Khimenko <khim@google.com> wrote:

> And move them to libnosys? This will work too, I think. There are sizable
> amount of functionality built around missing functions (things like
> signals). It all can not be used with nacl but since usually it's exception
> handling of some sort it worked fine when linked with -lnosys.
>

If there are entry points that cannot possibly work, they should be replaced
with nosys stubs, yes.


>
>
>> An application should always put -lnosys last among their own -l switches.
>>  Then
>> references from some other -lfoo will be just fine.
>>
>> I'm not even sure things like lidstdc++ and/or libfortran can be fully
> implemented without -lnosys.
>

If  -lstdc++ or -lgfortran require -lnosys and it's really the best thing to
leave them that way rather than dike out the code that has the dependencies,
then the right place for a magic -lnosys kludge is in g++spec.c and/or
gfortranspec.c, or by installing libstdc++.a/libgfortran.a as linker scripts
that refer to libnosys.a.

I don't know how to find/build/test naclports, but I can try.
>> If anything in there is using -lnosys and failing to put it last among
>> libraries
>> specified in a link, that should just be fixed there.
>>
>> What will it buy us?
>

I found two places in naclports needing the trivial change, and those will
go in shortly.

I don't understand what you are asking about here.  Fixing naclports link
lines to be correct buys correctness of naclports link lines.
Removing the magic treatment of -lnosys buys sanity points and
maintainability of the toolchain.

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[khimg, 2011-06-09 14:10:41]

On Thu, Jun 9, 2011 at 1:32 AM, Roland McGrath <mcgrathr@google.com> wrote:

> On Wed, Jun 8, 2011 at 2:15 PM, Victor Khimenko <khim@google.com> wrote:
>
>> And move them to libnosys? This will work too, I think. There are sizable
>> amount of functionality built around missing functions (things like
>> signals). It all can not be used with nacl but since usually it's exception
>> handling of some sort it worked fine when linked with -lnosys.
>>
>
> If there are entry points that cannot possibly work, they should be
> replaced with nosys stubs, yes.
>

Well, someone should do that or at least file a bug.


> An application should always put -lnosys last among their own -l switches.
>>>  Then
>>> references from some other -lfoo will be just fine.
>>>
>>> I'm not even sure things like lidstdc++ and/or libfortran can be fully
>> implemented without -lnosys.
>>
>
> If  -lstdc++ or -lgfortran require -lnosys and it's really the best thing
> to leave them that way rather than dike out the code that has the
> dependencies, then the right place for a magic -lnosys kludge is in
> g++spec.c and/or gfortranspec.c, or by installing libstdc++.a/libgfortran.a
> as linker scripts that refer to libnosys.a.
>
>
Ok. We probably can wait till people will actually hit the problems.


>  I don't know how to find/build/test naclports, but I can try.
>>> If anything in there is using -lnosys and failing to put it last among
>>> libraries
>>> specified in a link, that should just be fixed there.
>>>
>>> What will it buy us?
>>
>
> I found two places in naclports needing the trivial change, and those will
> go in shortly.
>
> Can you commit them first or at least add link to description of this CL?


> I don't understand what you are asking about here.
>

I mean literally: to make this change usable you need bunch of changes in
other places. And the end result is five lines removed from codebase of few
millions. What is the justification for all that change?


>  Fixing naclports link lines to be correct buys correctness of naclports
> link lines.
>

Define "correctness".


> Removing the magic treatment of -lnosys buys sanity points and
> maintainability of the toolchain.
>

How do you define your "sanity points" ? What kind of problems we are trying
to fix? AFAICS all versions of GCC from GCC 2.95 to GCC 4.6.0 are easily
patchable in this place so what's this mystic "maintainability" we buy here?

So far I see the need to add three additional CLs to make this one possible.
This is non-trivial amount of work. Why are we doing this and what kind of
work it simplifies?

If you are happy to deal with the fallout then this change LGTM (it DOES
save few lines and make the GCC patch more upstreamable). But I'm not sure
what's the urgency here.

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[eaeltsin, 2011-06-09 14:29:28]

Victor's answer above is in fact LGTM :-)