svn commit: r384894 - head/lang/gcc5-aux

[Tijl Coosemans]

On Tue, 28 Apr 2015 17:47:12 +0200 John Marino <freebsd.contact at marino.st> wrote:
> On 4/28/2015 17:36, Tijl Coosemans wrote:
>> On Tue, 28 Apr 2015 17:21:24 +0200 John Marino <freebsd.contact at marino.st> wrote:
>> Yes, the CPPFLAGS you left only affects the first configure script and
>> that script doesn't pass CPPFLAGS/LIBS to the Makefile it creates.  That
>> Makefile then runs multiple other configure scripts during build phase.
>> The only way I found to pass CPPFLAGS/LIBS to these other configure
>> scripts was *_configargs.
> 
> I believe you, but that sounds like the gcc build system is broken then.
> 
>>> From your answer, I infer it wasn't linking with libiconv before your
>>> commit?
>> 
>> It was when libiconv happened to be installed, but with my commit
>> libiconv is always installed as a build dependency on FreeBSD 10
>> (because the iconv.h header on FreeBSD 10 is broken). 
> 
> Maybe NLS is too much a pain to support.  Is there a reason that the
> lang/gccX don't support it?  I only threw it in because it seemed to
> work, but it is starting to be too much trouble, especially if it's not
> standard for ports compiler to support it.
> 
>> Hmm, can you do a build with only 1 make job?
> 
> I have a new commit brewing that changes a few things:
> 1. new bootstrap for DragonFly
> 2. new option to build all 3 stages (currently the standard)
> 3. new standard behavior to build only one stage, but without libcc1
> being produce which is the reason this wasn't set yet.
> 
> I was going to make new bootstraps for FreeBSD but now I don't think
> it's necessary.  I'm testing the build on FreeBSD 10 and FreeBSD 8 right
> now.  (10 just passed).
> 
> I can try to build with one job after that but it seems to me the issue
> is putting -L argument in args instead of LDFLAGS.  I thought LIBS was
> limited to libraries and wasn't supposed to carry flags but the whole
> LIBS thing has never been really clear to me either.

If possible -L should go in LIBS because it appears last on the command
line and LDFLAGS at the start.  Flags like -L/usr/local/lib should
come after any -L flags used by upstream such that it is searched last.

The command that fails on Dragonfly seems exactly the same as on
FreeBSD 10.  There's no -L/usr/local/lib there either.  The reason it
doesn't fail on FreeBSD is probably because gcc searches /usr/local/lib
implicitly (which I always found strange).  Maybe that is not the case
on Dragonfly.  Does this command work for instance:

echo 'int main(void) { return 0; }' | gcc5 -x c -o test - -lintl