Hello Joseph, Thanks for getting back to me on this!
> On 19 Jun 2018, at 17:50, Joseph Myers <jos...@codesourcery.com> wrote: > > On Thu, 7 Jun 2018, Olivier Hainque wrote: > >> An updated version of the patch is attached, accounting for >> your two comments and expanding on the .texi documentation a >> bit. > > I see you're not changing LINK_GCC_C_SEQUENCE_SPEC in arc/elf.h. That's a > slightly odd case in that it isn't actually using %L, but is using -lc > directly, whereas there's an empty definition of LIB_SPEC. Indeed. I hadn't changed it because it was only added very recently (like last week or so) and so wasn't there when I shaped the patch. > I'd expect the documentation to say something about libraries added only > for particular languages by the front-end drivers (-lstdc++ -lm, > -lgfortran -lm, etc.). It may be that the option isn't particularly > meaningful for code using such front-end drivers that add those libraries, > because those libraries depend on libc (and code in those languages will > generally depend on their libraries), but it should still say what the > effects are. Agreed. Attached is an updated version with the doc reworded to this effect, referring to "the system C library or system libraries tightly coupled with it", as opposed to "toolchain provided language support libraries". -lm is a bit annoying. There are very few explicit occurrences as this is usually to be added by users. Still, among the few that are there, some are in LIB_SPEC and some are not. I have qualified this with a "in some configurations" which has the advantage on conveying honestly that the effect isn't very precisely defined. It has been working well for the uses we had, indeed on bareboard configurations which is the stated intent. Reboostrapping on x86_64-linux now. If there's meaningful extra testing you think I could make, I'll be happy to comply. Thanks again for your input. With Kind Regards, Olivier
nolibc2.diff
Description: Binary data
