Re: amd64 bulk build failures (2018-10-25) - glabels / libtool

2018-10-27 Thread Christian Weisgerber
Sebastien Marie:

> So ld.lld uses RUNPATH instead of RPATH, and as libtool only uses RPATH
> to infer no standard directories... it fail to found the library.

Great analysis!

> The following diff on libtool permits to productivity/glabels to build.

ok naddy@

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: amd64 bulk build failures (2018-10-25) - glabels / libtool

2018-10-27 Thread Marc Espie
On Sat, Oct 27, 2018 at 09:29:21AM +0200, Sebastien Marie wrote:
> On Fri, Oct 26, 2018 at 05:24:26PM +0200, Christian Weisgerber wrote:
> > 
> > Remaining failures from the switch to lld:
> > 
> > mail/evolution-rss  edbus-private not found
> > net/telepathy/folks edbus-private not found
> > productivity/glabelsedbus-private not found
> 
> I took a look at glabels, and I am assuming others ports have similar
> problem.
> 
> The error log is:
> 
> /usr/bin/libtool  --tag=CC   --mode=link cc ...
> warning: could not find a edbus-private library
> Link error: edbus-private not found!
>  at /usr/libdata/perl5/LT/Library.pm line 137.
>   LT::Library::resolve_library(LT::Library=HASH(0x126c6fa79898), 
> ARRAY(0x126c06720070), 1, undef, "LT::Program") called at 
> /usr/libdata/perl5/LT/Mode/Link/Program.pm line 84
>   LT::Linker::Program::link(LT::Linker::Program=HASH(0x126c6fa76868), 
> LT::Program=HASH(0x126c329be310), ARRAY(0x126c0aee3cd0), 
> LT::OSConfig=HASH(0x126c975caac0), ARRAY(0x126c06720070), 
> LT::Library::Stash=HASH(0x126c06720028), ARRAY(0x126c0aee3f88), 
> ARRAY(0x126c10a22058), ...) called at 
> /usr/libdata/perl5/LT/Mode/Link/Program.pm line 28
>   LT::Program::link(LT::Program=HASH(0x126c329be310), 
> ARRAY(0x126c0aee3cd0), LT::OSConfig=HASH(0x126c975caac0), 
> ARRAY(0x126c06720070), LT::Library::Stash=HASH(0x126c06720028), 
> ARRAY(0x126c0aee3f88), ARRAY(0x126c10a22058), 
> LT::Parser=HASH(0x126c329be598), ...) called at 
> /usr/libdata/perl5/LT/Mode/Link.pm line 235
>   LT::Mode::Link::run(LT::Mode::Link=HASH(0x126c329beb50), 
> ARRAY(0x126c0aee3cd0), LT::Options=HASH(0x126c0aee3b20), 
> LT::OSConfig=HASH(0x126c975caac0)) called at /usr/bin/libtool line 428
> 
> it is libtool that generate an error because it didn't found
> edbus-private library.
> 
> This particular library comes from databases/evolution-data-server :
> 
> $ pkg_locate edbus-private
> evolution-data-server-3.28.5:databases/evolution-data-server:/usr/local/lib/evolution-data-server/libedbus-private.so
> 
> 
> So with ld.lld, libtool is unable to found the library.
> 
> I am able to reproduce the problem with just the following command line:
> 
> $ libtool --tag=CC --mode=link cc -v -o test -lebook-1.2
> warning: could not find a edbus-private library
> Link error: edbus-private not found!
> ...
> 
> 
> For what I understood, libtool uses objdump -p libebook-1.2.so to found
> the path dependencies (I have ktraced libtool).
> 
> On pre-ld.lld system, I have the following output:
> 
> $ objdump -p /usr/local/lib/libebook-1.2.so.21.0
> ...
> Dynamic Section:
>   NEEDED  libedata-book-1.2.so.18.0
>   ...
>   NEEDED  libedbus-private.so
>   ...
>   RPATH   /usr/local/lib/evolution-data-server
>   ...
> 
> But on post-ld.lld, the output is slightly different:
> 
> $ objdump -p /usr/local/lib/libebook-1.2.so.21.0
> ...
> Dynamic Section:
>   RUNPATH /usr/local/lib/evolution-data-server
>   NEEDED  libedata-book-1.2.so
>   ...
>   NEEDED  libedbus-private.so
>   ...
> 
> 
> So ld.lld uses RUNPATH instead of RPATH, and as libtool only uses RPATH
> to infer no standard directories... it fail to found the library.
> 
> The following diff on libtool permits to productivity/glabels to build.
> 
> 
> Index: LT/Library.pm
> ===
> RCS file: /cvs/src/usr.bin/libtool/LT/Library.pm,v
> retrieving revision 1.12
> diff -u -p -r1.12 Library.pm
> --- LT/Library.pm 21 Sep 2015 08:49:06 -  1.12
> +++ LT/Library.pm 27 Oct 2018 07:26:13 -
> @@ -191,7 +191,7 @@ sub inspect
>   return @deps;
>  }
>  
> -# give the list of RPATH directories
> +# give the list of RPATH/RUNPATH directories
>  sub findrpaths
>  {
>   my $self = shift;
> @@ -203,16 +203,20 @@ sub findrpaths
>   say "warning: library was specified that could not be found: 
> $self->{key}";
>   return;
>   }
> - tsay {"inspecting $filename for non standard RPATH..."};
> + tsay {"inspecting $filename for non standard RPATH/RUNPATH..."};
>   open(my $fh, '-|', "objdump", "-p", "--", $filename);
>   while (<$fh>) {
>   if (m/RPATH\s+(.*)$/) {
>   @dirs = split(":", $1);
>   last;
>   }
> + if (m/RUNPATH\s+(.*)$/) {
> + @dirs = split(":", $1);
> + last;
> + }
>   }
>   tsay {"found ", (@dirs == 0) ? 'none ' : '',
> - "RPATH for $filename\n@dirs"};
> + "RPATH/RUNPATH for $filename\n@dirs"};
>   return @dirs;
>  }
I would refactor it to use 
if (m/R(?:UN)?PATH\s+(.*)$/) {
instead, but apart from that, obviously okay.



Re: amd64 bulk build failures (2018-10-25) - glabels / libtool

2018-10-27 Thread Peter Hessler
On 2018 Oct 27 (Sat) at 09:48:53 +0200 (+0200), Landry Breuil wrote:
:On Sat, Oct 27, 2018 at 09:29:21AM +0200, Sebastien Marie wrote:
:> On Fri, Oct 26, 2018 at 05:24:26PM +0200, Christian Weisgerber wrote:
:> > 
:> > Remaining failures from the switch to lld:
:> > 
:> > mail/evolution-rss  edbus-private not found
:> > net/telepathy/folks edbus-private not found
:> > productivity/glabelsedbus-private not found
:> 
:> I took a look at glabels, and I am assuming others ports have similar
:> problem.
:> 
:> So ld.lld uses RUNPATH instead of RPATH, and as libtool only uses RPATH
:> to infer no standard directories... it fail to found the library.
:> 
:> The following diff on libtool permits to productivity/glabels to build.
:
:The analysis feels 100% correct, and the diff reads fine. As it will
:only reinstating a behaviour that was present with ld.bfd, imo it cant
:cause breakage, and might even fix other lld-related breakage..
:will put it on my (slow, 48h) builder, but i guess ajacoutot will beat
:me to it :)
:
:Landry
:

from my reading of 
http://www.sco.com/developers/gabi/2000-07-17/ch5.dynamic.html#shobj_dependencies
and the ld.lld man page, this is correct.

OK

-- 
Weiler's Law:
Nothing is impossible for the man who doesn't have to do it
himself.



Re: amd64 bulk build failures (2018-10-25) - glabels / libtool

2018-10-27 Thread Landry Breuil
On Sat, Oct 27, 2018 at 09:29:21AM +0200, Sebastien Marie wrote:
> On Fri, Oct 26, 2018 at 05:24:26PM +0200, Christian Weisgerber wrote:
> > 
> > Remaining failures from the switch to lld:
> > 
> > mail/evolution-rss  edbus-private not found
> > net/telepathy/folks edbus-private not found
> > productivity/glabelsedbus-private not found
> 
> I took a look at glabels, and I am assuming others ports have similar
> problem.
> 
> So ld.lld uses RUNPATH instead of RPATH, and as libtool only uses RPATH
> to infer no standard directories... it fail to found the library.
> 
> The following diff on libtool permits to productivity/glabels to build.

The analysis feels 100% correct, and the diff reads fine. As it will
only reinstating a behaviour that was present with ld.bfd, imo it cant
cause breakage, and might even fix other lld-related breakage..
will put it on my (slow, 48h) builder, but i guess ajacoutot will beat
me to it :)

Landry



Re: amd64 bulk build failures (2018-10-25) - glabels / libtool

2018-10-27 Thread Sebastien Marie
On Fri, Oct 26, 2018 at 05:24:26PM +0200, Christian Weisgerber wrote:
> 
> Remaining failures from the switch to lld:
> 
> mail/evolution-rss  edbus-private not found
> net/telepathy/folks edbus-private not found
> productivity/glabelsedbus-private not found

I took a look at glabels, and I am assuming others ports have similar
problem.

The error log is:

/usr/bin/libtool  --tag=CC   --mode=link cc ...
warning: could not find a edbus-private library
Link error: edbus-private not found!
 at /usr/libdata/perl5/LT/Library.pm line 137.
LT::Library::resolve_library(LT::Library=HASH(0x126c6fa79898), 
ARRAY(0x126c06720070), 1, undef, "LT::Program") called at 
/usr/libdata/perl5/LT/Mode/Link/Program.pm line 84
LT::Linker::Program::link(LT::Linker::Program=HASH(0x126c6fa76868), 
LT::Program=HASH(0x126c329be310), ARRAY(0x126c0aee3cd0), 
LT::OSConfig=HASH(0x126c975caac0), ARRAY(0x126c06720070), 
LT::Library::Stash=HASH(0x126c06720028), ARRAY(0x126c0aee3f88), 
ARRAY(0x126c10a22058), ...) called at 
/usr/libdata/perl5/LT/Mode/Link/Program.pm line 28
LT::Program::link(LT::Program=HASH(0x126c329be310), 
ARRAY(0x126c0aee3cd0), LT::OSConfig=HASH(0x126c975caac0), 
ARRAY(0x126c06720070), LT::Library::Stash=HASH(0x126c06720028), 
ARRAY(0x126c0aee3f88), ARRAY(0x126c10a22058), LT::Parser=HASH(0x126c329be598), 
...) called at /usr/libdata/perl5/LT/Mode/Link.pm line 235
LT::Mode::Link::run(LT::Mode::Link=HASH(0x126c329beb50), 
ARRAY(0x126c0aee3cd0), LT::Options=HASH(0x126c0aee3b20), 
LT::OSConfig=HASH(0x126c975caac0)) called at /usr/bin/libtool line 428

it is libtool that generate an error because it didn't found
edbus-private library.

This particular library comes from databases/evolution-data-server :

$ pkg_locate edbus-private
evolution-data-server-3.28.5:databases/evolution-data-server:/usr/local/lib/evolution-data-server/libedbus-private.so


So with ld.lld, libtool is unable to found the library.

I am able to reproduce the problem with just the following command line:

$ libtool --tag=CC --mode=link cc -v -o test -lebook-1.2
warning: could not find a edbus-private library
Link error: edbus-private not found!
...


For what I understood, libtool uses objdump -p libebook-1.2.so to found
the path dependencies (I have ktraced libtool).

On pre-ld.lld system, I have the following output:

$ objdump -p /usr/local/lib/libebook-1.2.so.21.0
...
Dynamic Section:
  NEEDED  libedata-book-1.2.so.18.0
  ...
  NEEDED  libedbus-private.so
  ...
  RPATH   /usr/local/lib/evolution-data-server
  ...

But on post-ld.lld, the output is slightly different:

$ objdump -p /usr/local/lib/libebook-1.2.so.21.0
...
Dynamic Section:
  RUNPATH /usr/local/lib/evolution-data-server
  NEEDED  libedata-book-1.2.so
  ...
  NEEDED  libedbus-private.so
  ...


So ld.lld uses RUNPATH instead of RPATH, and as libtool only uses RPATH
to infer no standard directories... it fail to found the library.

The following diff on libtool permits to productivity/glabels to build.


Index: LT/Library.pm
===
RCS file: /cvs/src/usr.bin/libtool/LT/Library.pm,v
retrieving revision 1.12
diff -u -p -r1.12 Library.pm
--- LT/Library.pm   21 Sep 2015 08:49:06 -  1.12
+++ LT/Library.pm   27 Oct 2018 07:26:13 -
@@ -191,7 +191,7 @@ sub inspect
return @deps;
 }
 
-# give the list of RPATH directories
+# give the list of RPATH/RUNPATH directories
 sub findrpaths
 {
my $self = shift;
@@ -203,16 +203,20 @@ sub findrpaths
say "warning: library was specified that could not be found: 
$self->{key}";
return;
}
-   tsay {"inspecting $filename for non standard RPATH..."};
+   tsay {"inspecting $filename for non standard RPATH/RUNPATH..."};
open(my $fh, '-|', "objdump", "-p", "--", $filename);
while (<$fh>) {
if (m/RPATH\s+(.*)$/) {
@dirs = split(":", $1);
last;
}
+   if (m/RUNPATH\s+(.*)$/) {
+   @dirs = split(":", $1);
+   last;
+   }
}
tsay {"found ", (@dirs == 0) ? 'none ' : '',
-   "RPATH for $filename\n@dirs"};
+   "RPATH/RUNPATH for $filename\n@dirs"};
return @dirs;
 }
 

Thanks.
-- 
Sebastien Marie