Re: GCC and as

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 05/19/18 09:41, Jason Bacon wrote:
> On 05/17/18 15:10, Joerg Sonnenberger wrote:
> > On Thu, May 17, 2018 at 12:43:56PM -0500, Jason Bacon wrote:
> > > /sharedapps/pkg-2018Q1/bin/gld: warning: libdl.so.2, needed by 
> > > /home/sharedapps/pkgsrc-2018Q1/fonts/harfbuzz/work/.buildlink/lib/libicuuc.so,
> > > not found (try using -rpath or -rpath-link)
> > This is the core issue. Find the library, figure out why it not in the
> > default search path and/or what rpath is missing. From the name, it
> > should be.
> >
> > Joerg
>
> Yeah, the first thing I tried was locating where libdl.so.2 was 
> installed, but apparently I botched my first attempt at
>
> find /lib* -name libdl\*
>
> Second try showed it in /lib64.
>
> The problem seems to be a hard-coded path in binutils/Makefile:
>
> CONFIGURE_ARGS+=    --with-lib-path='/lib:/usr/lib'
>
> After adding '/lib64:/usr/lib64:', I'm able to build a test package 
> successfully.
>
> New problem, though.  For verification, I reversed the patch, rebuilt 
> and reinstalled binutils, and my test package still builds even though 
> it should not.  :-/
>
> Starting with a fresh tree again, which will take a while as I have to 
> build gcc5 from source.
OK, simple problem: wrong test package.

I've now verified the patches below in a pristine pkgsrc tree using 
net/wget to test for the libdl issue.  There may be a tidier way to 
append things to LIB_PATH.

Of course, we'll need the same patch for other gcc packages.  I 
confirmed that the code generator going back to at least GCC 4.9 is 
incompatible with CentOS 6 as.

As it stands, this will cause an unnecessary binutils dep for at least 
some gcc packages on CentOS 7, which has a binutils new enough for at 
least gcc5.  We could add a check for the RHEL version as well and limit 
the patch to RHEL/CentOS 6 for now.  I suspect the problem will show up 
in RHEL/CentOS 7 at some point, though, and pkgsrc gcc packages will 
move forward and /usr/bin/as will not.  A binutils dep seems to me like 
a small price to ensure that this issue doesn't return.

Looking at Lewis's suggestion of testing the binutils version rather 
than OS_VARIANT in the gcc5 patch, I'm not sure exactly how to safely 
implement it.  Do we assume that the "base" binutils is first in the 
default PATH?  Trusting PATH could pick up pkgsrc binutils, disabling 
the dependency during gcc build and allowing binutils to be deinstalled 
without warning, which would break future package builds.  If we don't 
trust path, what absolute path names do we check for?  Can we assume 
that "as" and "ld" are in /usr/bin on all Linux distros?

Suggestions welcome...

cvs diff: Diffing .
Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/devel/binutils/Makefile,v
retrieving revision 1.76
diff -r1.76 Makefile
34d33
< CONFIGURE_ARGS+=    --with-lib-path='/lib:/usr/lib'
35a35,44
> .if exists(/lib64)
> . if exists(/usr/lib64)
> LIB_PATH=    '/lib64:/usr/lib64:/lib:/usr/lib'
> . else
> LIB_PATH=    '/lib64:/lib:/usr/lib'
> . endif
> .else
> LIB_PATH=    '/lib:/usr/lib'
> .endif
> CONFIGURE_ARGS+=    --with-lib-path=${LIB_PATH}
cvs diff: Diffing patches

cvs diff: Diffing .
Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/lang/gcc5/Makefile,v
retrieving revision 1.27
diff -r1.27 Makefile
133a134,140
> .if ${OS_VARIANT} == "redhat"
> CONFIGURE_ARGS+=    --with-gnu-as --with-as=${PREFIX}/bin/gas
> CONFIGURE_ARGS+=    --with-gnu-ld --with-ld=${PREFIX}/bin/gld
> .  include "../../devel/binutils/buildlink3.mk"
> BUILDLINK_DEPMETHOD.binutils=    full
> .endif
>
cvs diff: Diffing patches