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