Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 03/06/2018 05:55 PM, Sérgio Basto wrote:

Again, IMHO, wiki page should be updated (add something like: -z defs
was postponed ... ) and still it should be added a link to
buildflags.md .


Okay, I made some edits.


BTW "%define _strict_symbol_defs_build 1" will enable -z defs ?


Yes.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Sérgio Basto]

On Tue, 2018-03-06 at 12:20 +0100, Florian Weimer wrote:
> On 03/05/2018 05:55 PM, Sérgio Basto wrote:
> > On Mon, 2018-01-22 at 16:24 +0100, Florian Weimer wrote:
> > > ### Disable strict symbol checks in the link editor (ld)
> > > 
> > > By default, the link editor will refuse to link shared objects
> > > which
> > > contain undefined symbols.  In some cases (such as when a DSO is
> > > loaded as a plugin and is expected to bind to symbols in the main
> > > executable), undefined symbols are expected.  In this case, you
> > > can
> > > add
> > > 
> > >   %undefine _strict_symbol_defs_build
> > > 
> > > to the RPM spec file to disable these strict
> > > checks.  Alternatively,
> > > you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the
> > > gcc
> > > command line).  The latter needs binutils 2.29.1-12.fc28 or
> > > later.
> > > 
> > > 
> > > This is also part of the build flags documentation at:
> > > 
> > >  > > /f/b
> > > uildflags.md>
> > IMHO, also in https://fedoraproject.org/wiki/Changes/BINUTILS2291
> > or
> > should link to  https://src.fedoraproject.org/rpms/redhat-rpm-confi
> > g/bl
> > ob/master/f/buildflags.md or should mention that we may use:
> > %undefine _strict_symbol_defs_build
> 
> The change was reverted, so this is currently not necessary.
> 
> The next change will discuss remedies.

Again, IMHO, wiki page should be updated (add something like: -z defs
was postponed ... ) and still it should be added a link to
buildflags.md . 

BTW "%define _strict_symbol_defs_build 1" will enable -z defs ? 


Thanks,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 03/05/2018 05:55 PM, Sérgio Basto wrote:

On Mon, 2018-01-22 at 16:24 +0100, Florian Weimer wrote:

### Disable strict symbol checks in the link editor (ld)

By default, the link editor will refuse to link shared objects which
contain undefined symbols.  In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.  In this case, you can
add

  %undefine _strict_symbol_defs_build

to the RPM spec file to disable these strict checks.  Alternatively,
you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
command line).  The latter needs binutils 2.29.1-12.fc28 or later.


This is also part of the build flags documentation at:





IMHO, also in https://fedoraproject.org/wiki/Changes/BINUTILS2291 or
should link to  https://src.fedoraproject.org/rpms/redhat-rpm-config/bl
ob/master/f/buildflags.md or should mention that we may use:
%undefine _strict_symbol_defs_build


The change was reverted, so this is currently not necessary.

The next change will discuss remedies.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Sérgio Basto]

On Mon, 2018-01-22 at 16:24 +0100, Florian Weimer wrote:
> ### Disable strict symbol checks in the link editor (ld)
> 
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols.  In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected.  In this case, you can
> add
> 
>  %undefine _strict_symbol_defs_build
> 
> to the RPM spec file to disable these strict checks.  Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line).  The latter needs binutils 2.29.1-12.fc28 or later.
> 
> 
> This is also part of the build flags documentation at:
> 
>  uildflags.md>

Hello, 
IMHO, also in https://fedoraproject.org/wiki/Changes/BINUTILS2291 or
should link to  https://src.fedoraproject.org/rpms/redhat-rpm-config/bl
ob/master/f/buildflags.md or should mention that we may use: 
%undefine _strict_symbol_defs_build

Thanks,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Petr Pisar]

On 2018-01-25, Petr Pisar  wrote:
> On 2018-01-25, Daniel P  Berrangé  wrote:
>> Not neccessarily - with perl, the APIs used by extensions are actually
>> in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
>> So perl binary modules ought to still build without undefined symbols,
>> as IIUC they're not relying on things in /usr/bin/perl
>>
> Perl fails too
>.
>
> While extensions link to libperl.so that itself links to libpthread.so
> that defines pthread_getspecific symbol, the extensions linking fails
> because they use dTHX macro, provided by included thread.h via perl.h,
> that expands to pthread_getspecific.
>
Fixed in perl-5.26.1-405.fc28. Since now all binary extensions will be
linked with -lpthread.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-29 16:51, Richard Shaw wrote:
On Mon, Jan 29, 2018 at 8:37 AM, Florian Weimer > wrote:


I have reverted the -z defs change in rawhide.  A substantial number
of underlinked binaries are still shipped in rawhide after this
change, either due to explicit overrides or incomplete build flags
injection. This means that it is necessary to review built RPM
packages for incorrectly linked binaries even after the change. 
Considering that -z defs also causes a lot of spurious build

failures, it's probably not the way to go.

(The work to enable -z defs is not lost—even after the revert,
packages which have been fixed so far will remain fixed.)


Would it make sense (or be a lot of work) to include this in the Koschei 
integration?


Wouldn't that make it so packages with issues could be reported without 
creating a lot of FTBFS issues?




Making koschei builds use -z defs, while regular Fedora builds wouldn't 
use it, is not possible by design (koschei only requests the builds from 
koji, it cannot make changes to the spec and cannot alter the buildroot).
But if the build only produced a warning (as suggested in other part of 
this thread), then it would be possible for koschei to parse the build 
log and indicate this somehow.

But I think taskotron is a better place for such checks.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Shaw]

On Mon, Jan 29, 2018 at 8:37 AM, Florian Weimer  wrote:

> I have reverted the -z defs change in rawhide.  A substantial number of
> underlinked binaries are still shipped in rawhide after this change, either
> due to explicit overrides or incomplete build flags injection. This means
> that it is necessary to review built RPM packages for incorrectly linked
> binaries even after the change.  Considering that -z defs also causes a lot
> of spurious build failures, it's probably not the way to go.
>
> (The work to enable -z defs is not lost—even after the revert, packages
> which have been fixed so far will remain fixed.)


Would it make sense (or be a lot of work) to include this in the Koschei
integration?

Wouldn't that make it so packages with issues could be reported without
creating a lot of FTBFS issues?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Mon, Jan 29, 2018 at 10:02 AM, Fabio Valentini  wrote:
> On Mon, Jan 29, 2018 at 3:37 PM, Florian Weimer  wrote:
>> I have reverted the -z defs change in rawhide.  A substantial number of
>> underlinked binaries are still shipped in rawhide after this change, either
>> due to explicit overrides or incomplete build flags injection. This means
>> that it is necessary to review built RPM packages for incorrectly linked
>> binaries even after the change.  Considering that -z defs also causes a lot
>> of spurious build failures, it's probably not the way to go.
>>
>> (The work to enable -z defs is not lost—even after the revert, packages
>> which have been fixed so far will remain fixed.)
>
> Maybe this change can be revisited for a later fedora release? I think
> there is a benefit in assuring that working libraries / biniares are
> produced.
>
> Also, would it be possible to print a warning instead of failing on
> detected underlinking?
> If so, I think build logs could be checked for the warning as part of
> the usual taskotron/bodhi(?) build checks, and errors could get fixed
> one by one (or ignored, in the case of false positives). That would
> provide the same benefit of checking all packages, but with much less
> overall impact on package builds (ideally, none).
>

It also sounds like it'd make sense to make this an opt-in change for
this release, so that we can incrementally fix things to make it
opt-out next release.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Fabio Valentini]

On Mon, Jan 29, 2018 at 3:37 PM, Florian Weimer  wrote:
> I have reverted the -z defs change in rawhide.  A substantial number of
> underlinked binaries are still shipped in rawhide after this change, either
> due to explicit overrides or incomplete build flags injection. This means
> that it is necessary to review built RPM packages for incorrectly linked
> binaries even after the change.  Considering that -z defs also causes a lot
> of spurious build failures, it's probably not the way to go.
>
> (The work to enable -z defs is not lost—even after the revert, packages
> which have been fixed so far will remain fixed.)

Maybe this change can be revisited for a later fedora release? I think
there is a benefit in assuring that working libraries / biniares are
produced.

Also, would it be possible to print a warning instead of failing on
detected underlinking?
If so, I think build logs could be checked for the warning as part of
the usual taskotron/bodhi(?) build checks, and errors could get fixed
one by one (or ignored, in the case of false positives). That would
provide the same benefit of checking all packages, but with much less
overall impact on package builds (ideally, none).

Fabio

>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

I have reverted the -z defs change in rawhide.  A substantial number of 
underlinked binaries are still shipped in rawhide after this change, 
either due to explicit overrides or incomplete build flags injection. 
This means that it is necessary to review built RPM packages for 
incorrectly linked binaries even after the change.  Considering that -z 
defs also causes a lot of spurious build failures, it's probably not the 
way to go.


(The work to enable -z defs is not lost—even after the revert, packages 
which have been fixed so far will remain fixed.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Petr Pisar]

On Thu, Jan 25, 2018 at 04:14:52PM +, Tom Hughes wrote:
> There seems to be a similar issue with perl extensions that use C++ failing
> to link due to missing libstdc++ symbols, eg:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24412387
> 
> I think in that case the issue is that libgdal is linked to libstdc++ but
> the perl GDAL.so module was wound up with direct references to symbols in
> libstdc++ but isn't linking to it directly.
> 
> So I think that needs a fix in gdal rather than changing the default
> libraries linked by perl.
> 
> In fact I guess the link should really use g++ not gcc? Not sure how easy
> that is to do in a perl extension build...
> 
Perl supports building using both C and C++ compilers. I did not checked gdal
build script, but if you use ExtUtils::MakeMaker, you can redefine CC value to
g++ in WriteMakefile() arguments in your Makefile.PL.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Kevin Fenzi]

On 01/25/2018 07:20 AM, Michael Cronenworth wrote:
> On 01/25/2018 08:50 AM, Peter Robinson wrote:
>> It did [1], and I'm fairly certain it was referenced on this thread
>> already too.
>>
>> [1]https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope
> 
> That's poorly advertised. I would not associate a Binutils version
> update with a LDFLAGS change.
> 
> The change should be broken into two changes. Disappointing that FESCo
> did not mandate that. Members should use this thread as an example they
> need improvement.

Do note that all changes are posted to devel-announce with discussion
here, so you also could have suggested splitting things.

I'm not sure splitting would have been good, but the name could have
been more descriptive here. :(

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 05:14 PM, Tom Hughes wrote:


There seems to be a similar issue with perl extensions that use C++ 
failing to link due to missing libstdc++ symbols, eg:


https://koji.fedoraproject.org/koji/taskinfo?taskID=24412387

I think in that case the issue is that libgdal is linked to libstdc++ 
but the perl GDAL.so module was wound up with direct references to 
symbols in libstdc++ but isn't linking to it directly.


So I think that needs a fix in gdal rather than changing the default 
libraries linked by perl.


In fact I guess the link should really use g++ not gcc?


Yes, shared object which use C++ and require C++ run-time library 
support need to be linked with g++.


However, this does not extend to clients—if the library has a C-only 
interface, then it can be linked with gcc into other libraries and 
applications.  The dynamic linker will take care of the rest.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Fri, Jan 26, 2018 at 08:45:28AM +, Richard W.M. Jones wrote:
> On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> > %undefine _strict_symbol_defs_build
> 
> I tried this to unbreak the linker, but it completely breaks gcc:
> 
>   configure: error: C compiler cannot create executables
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24460823

This scratch build dumps out the config.log file after the
failure so there's more information:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=24461751

I'm not sure if this is the same or different error though:

  configure:5617: gcc -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection  -Wl,-z,relro  
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c  >&5
  annobin: conftest.c: Error: plugin built for compiler version (7.3.1) but run 
with compiler version (7.2.1)
  cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Paul Howarth]

On Fri, 26 Jan 2018 08:45:28 +
"Richard W.M. Jones"  wrote:

> On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> > %undefine _strict_symbol_defs_build  
> 
> I tried this to unbreak the linker, but it completely breaks gcc:
> 
>   configure: error: C compiler cannot create executables
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24460823

This is an unrelated issue: see the "GCC broken in rawhide?" thread.

I've had lots of koschei reports as a result of that.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> %undefine _strict_symbol_defs_build

I tried this to unbreak the linker, but it completely breaks gcc:

  configure: error: C compiler cannot create executables

https://koji.fedoraproject.org/koji/taskinfo?taskID=24460823

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 15:58, Florian Weimer wrote:

On 01/25/2018 04:37 PM, Petr Pisar wrote:

On 2018-01-25, Daniel P  Berrangé  wrote:

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.


Interesting.  This leads to:

$ eu-readelf --symbols=.dynsym /usr/lib64/perl5/auto/POSIX/POSIX.so | 
grep specific
    52:   0 NOTYPE  GLOBAL DEFAULT    UNDEF 
pthread_getspecific


So the symbol version is missing, and there is no guarantee for 
compatibility with future glibc versions. 8-(


This is exactly the kind of problem -z defs intends to catch.


There seems to be a similar issue with perl extensions that use C++ 
failing to link due to missing libstdc++ symbols, eg:


https://koji.fedoraproject.org/koji/taskinfo?taskID=24412387

I think in that case the issue is that libgdal is linked to libstdc++ 
but the perl GDAL.so module was wound up with direct references to 
symbols in libstdc++ but isn't linking to it directly.


So I think that needs a fix in gdal rather than changing the default 
libraries linked by perl.


In fact I guess the link should really use g++ not gcc? Not sure how 
easy that is to do in a perl extension build...


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:37 PM, Petr Pisar wrote:

On 2018-01-25, Daniel P  Berrangé  wrote:

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.


Interesting.  This leads to:

$ eu-readelf --symbols=.dynsym /usr/lib64/perl5/auto/POSIX/POSIX.so | 
grep specific
   52:   0 NOTYPE  GLOBAL DEFAULTUNDEF 
pthread_getspecific


So the symbol version is missing, and there is no guarantee for 
compatibility with future glibc versions. 8-(


This is exactly the kind of problem -z defs intends to catch.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:51 PM, Richard Hughes wrote:

On 25 January 2018 at 14:52, Florian Weimer  wrote:

../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572

Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648


Agreed.


I can perhaps put a workaround in redhat-rpm-config, which should make it
much less likely that this compiler bug is encountered.


Should I avoid building my packages on rawhide until that workaround
is done? This seems kinda late in the cycle to be playing compiler
whack-a-mole...


rawhide should have a workaround in place, see my other message.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:52, Florian Weimer  wrote:
>> ../src/fu-device-locker.c:49:1: internal compiler error: in
>> ix86_expand_prologue, at config/i386/i386.c:14572
> Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648

Agreed.

> I can perhaps put a workaround in redhat-rpm-config, which should make it
> much less likely that this compiler bug is encountered.

Should I avoid building my packages on rawhide until that workaround
is done? This seems kinda late in the cycle to be playing compiler
whack-a-mole...

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Sérgio Basto]

On Thu, 2018-01-25 at 14:50 +, Peter Robinson wrote:
> On Thu, Jan 25, 2018 at 2:21 PM, Michael Cronenworth  > wrote:
> > On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:
> > > 
> > > I think the -z defs change should be reverted.  It breaks very
> > > long-
> > > standing expected behaviour of linkers and there's been no proper
> > > justification for doing it.
> > 
> > 
> > +1
> > 
> > This should go through a Fedora Change workflow. I am unaware of a
> > Fedora
> > Change for this.
> 
> It did [1], and I'm fairly certain it was referenced on this thread
> already too.
> 
> [1] https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope

2016-11-15  Fedora 25 Release
2017-02-28  Branch Fedora 26 from Rawhide (Rawhide becomes future F27)

2017-07-11  Fedora 26 Release
2017-08-15  Branch Fedora 27 from Rawhide (Rawhide becomes future F28)

2017-11-14  Fedora 27 Release
2018-02-20  Branch Fedora 28 from Rawhide (Rawhide becomes future F29)

Can we do branch more early ? (like Branch Fedora 27 , but not at same
time of EOL of previous release  because I going crazy , every time I
rebuild something in rawhide it won't build because some new feature . 

This -z breaks openv (on python2 module), clamav (I guess  , kodi , and
god knows what more ... 

This rawhide in open since 2017-08-15 , after 5 months , we decide add 
this breaking feature , more gcc8 and his new lessons that abs(of
unsigned ) is redundant so we won't build it . 

so +1 (-z defs change should be reverted)


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Petr Pisar]

On 2018-01-25, Daniel P  Berrangé  wrote:
> Not neccessarily - with perl, the APIs used by extensions are actually
> in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
> So perl binary modules ought to still build without undefined symbols,
> as IIUC they're not relying on things in /usr/bin/perl
>
Perl fails too
.

While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.

In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.

I don't say this not a bug in Perl, but just that Perl is affected.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Michael Cronenworth]

On 01/25/2018 08:50 AM, Peter Robinson wrote:

It did [1], and I'm fairly certain it was referenced on this thread already too.

[1]https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope


That's poorly advertised. I would not associate a Binutils version update with a 
LDFLAGS change.


The change should be broken into two changes. Disappointing that FESCo did not 
mandate that. Members should use this thread as an example they need improvement.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 04:04 PM, Fabio Valentini wrote:

Yes, this is:https://bugzilla.redhat.com/show_bug.cgi?id=1538648

I can perhaps put a workaround in redhat-rpm-config, which should make it
much less likely that this compiler bug is encountered.  Rebuilding gcc
takes 15+ hours, unfortunately, and untagging it will only revert to a
version which miscompiles OpenSSH and RPM. 8-(



Honestly, if the "-z defs" change leads to such


The above is a unrelated compiler bug, not related to -z defs.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Fabio Valentini]

On Thu, Jan 25, 2018 at 3:52 PM, Florian Weimer  wrote:
> On 01/25/2018 03:45 PM, Richard Hughes wrote:
>>
>> On 25 January 2018 at 14:28, Richard Hughes  wrote:
>>>
>>> Was there a test mass rebuild? If so, how many packages need fixes? I
>>> got bitten by this just now and it would have been nice to fix the
>>> problems upstream before Fedora rebuilds just started failing.
>>
>>
>> Replying to myself, trying to fix it (by adding the "missing" private
>> library to the plugins) and rebuilding I triggered a gcc bug on i386:
>>
>> *** WARNING *** there are active plugins, do not report this as a bug
>> unless you can reproduce it without enabling any plugins.
>> Event| Plugins
>> PLUGIN_FINISH_UNIT   | Generate final annotations
>> PLUGIN_START_UNIT| Generate global annotations
>> PLUGIN_ALL_PASSES_END| Generate per-function annotations
>> ../src/fu-device-locker.c: In function
>> 'fu_device_locker_class_intern_init':
>> ../src/fu-device-locker.c:49:1: internal compiler error: in
>> ix86_expand_prologue, at config/i386/i386.c:14572
>>   G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)
>
>
> Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648
>
> I can perhaps put a workaround in redhat-rpm-config, which should make it
> much less likely that this compiler bug is encountered.  Rebuilding gcc
> takes 15+ hours, unfortunately, and untagging it will only revert to a
> version which miscompiles OpenSSH and RPM. 8-(

Honestly, if the "-z defs" change leads to such massive problems,
maybe it really should be considered to revert this change for f28 -
if only to give upstream developers and package maintainers more time
for fixes. I can imagine overworked maintainers with dozens of broken
packages ignoring the issues or just putting the "%undef" into their
packages without investigating (which would cost more time), possibly
obscuring real issues. I think enabling this change again right after
the f28 mass rebuild and branching would be the best, giving
maintainers the most time.

Fabio

> Thanks,
> Florian
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/25/2018 03:45 PM, Richard Hughes wrote:

On 25 January 2018 at 14:28, Richard Hughes  wrote:

Was there a test mass rebuild? If so, how many packages need fixes? I
got bitten by this just now and it would have been nice to fix the
problems upstream before Fedora rebuilds just started failing.


Replying to myself, trying to fix it (by adding the "missing" private
library to the plugins) and rebuilding I triggered a gcc bug on i386:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | Generate final annotations
PLUGIN_START_UNIT| Generate global annotations
PLUGIN_ALL_PASSES_END| Generate per-function annotations
../src/fu-device-locker.c: In function 'fu_device_locker_class_intern_init':
../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572
  G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)


Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648

I can perhaps put a workaround in redhat-rpm-config, which should make 
it much less likely that this compiler bug is encountered.  Rebuilding 
gcc takes 15+ hours, unfortunately, and untagging it will only revert to 
a version which miscompiles OpenSSH and RPM. 8-(


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Peter Robinson]

On Thu, Jan 25, 2018 at 2:21 PM, Michael Cronenworth  wrote:
> On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:
>>
>> I think the -z defs change should be reverted.  It breaks very long-
>> standing expected behaviour of linkers and there's been no proper
>> justification for doing it.
>
>
> +1
>
> This should go through a Fedora Change workflow. I am unaware of a Fedora
> Change for this.

It did [1], and I'm fairly certain it was referenced on this thread already too.

[1] https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:28, Richard Hughes  wrote:
> Was there a test mass rebuild? If so, how many packages need fixes? I
> got bitten by this just now and it would have been nice to fix the
> problems upstream before Fedora rebuilds just started failing.

Replying to myself, trying to fix it (by adding the "missing" private
library to the plugins) and rebuilding I triggered a gcc bug on i386:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | Generate final annotations
PLUGIN_START_UNIT| Generate global annotations
PLUGIN_ALL_PASSES_END| Generate per-function annotations
../src/fu-device-locker.c: In function 'fu_device_locker_class_intern_init':
../src/fu-device-locker.c:49:1: internal compiler error: in
ix86_expand_prologue, at config/i386/i386.c:14572
 G_DEFINE_TYPE (FuDeviceLocker, fu_device_locker, G_TYPE_OBJECT)
 ^

Other architectures build fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24438792

I've also did a test build of the "fix" on our upstream Travis CI,
which has now started failing on clang, but not gcc:
https://travis-ci.org/hughsie/fwupd/jobs/333283947

What a giant waste of time.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Hughes]

On 25 January 2018 at 14:21, Michael Cronenworth  wrote:
> This should go through a Fedora Change workflow. I am unaware of a Fedora
> Change for this.

Was there a test mass rebuild? If so, how many packages need fixes? I
got bitten by this just now and it would have been nice to fix the
problems upstream before Fedora rebuilds just started failing.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Michael Cronenworth]

On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:

I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


+1

This should go through a Fedora Change workflow. I am unaware of a Fedora Change for 
this.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Thu, Jan 25, 2018 at 6:33 AM, Daniel P. Berrangé  wrote:
> On Thu, Jan 25, 2018 at 08:40:29AM +, Tom Hughes wrote:
>> On 25/01/18 07:31, Remi Collet wrote:
>> > Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>> > > I updated redhat-rpm-config to instruct ld to reject linking shared
>> > > objects with undefined symbols.  Such undefined symbols break symbol
>> > > versioning because the are not necessarily bound to the correct symbol
>> > > version at run time.  (rhbz#1535422)
>> >
>> > So this break all the PHP stack build...
>> >
>> > (all php extensions are dl open plugins, relying on symbol from the engine)
>>
>> Yes it broke all the nodejs binary modules as well, so I fixed them.
>>
>> Doubtless it will do the same for perl, ruby, python, etc.
>
> Not neccessarily - with perl, the APIs used by extensions are actually
> in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
> So perl binary modules ought to still build without undefined symbols,
> as IIUC they're not relying on things in /usr/bin/perl
>

As I understand it, it's the same way for most Python extensions, too.
Just not the ones that rely on ctypes (aka dlopen), like
python-libarchive-c, and whatnot.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P . Berrangé]

On Thu, Jan 25, 2018 at 08:40:29AM +, Tom Hughes wrote:
> On 25/01/18 07:31, Remi Collet wrote:
> > Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> > > I updated redhat-rpm-config to instruct ld to reject linking shared
> > > objects with undefined symbols.  Such undefined symbols break symbol
> > > versioning because the are not necessarily bound to the correct symbol
> > > version at run time.  (rhbz#1535422)
> > 
> > So this break all the PHP stack build...
> > 
> > (all php extensions are dl open plugins, relying on symbol from the engine)
> 
> Yes it broke all the nodejs binary modules as well, so I fixed them.
> 
> Doubtless it will do the same for perl, ruby, python, etc.

Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Vít Ondruch]

Dne 25.1.2018 v 09:40 Tom Hughes napsal(a):
> On 25/01/18 07:31, Remi Collet wrote:
>> Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>>> I updated redhat-rpm-config to instruct ld to reject linking shared
>>> objects with undefined symbols.  Such undefined symbols break symbol
>>> versioning because the are not necessarily bound to the correct symbol
>>> version at run time.  (rhbz#1535422)
>>
>> So this break all the PHP stack build...
>>
>> (all php extensions are dl open plugins, relying on symbol from the
>> engine)
>
> Yes it broke all the nodejs binary modules as well, so I fixed them.
>
> Doubtless it will do the same for perl, ruby, python, etc.

I have not yet met any issues with Ruby. Just saying 


V.

>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-23 20:06, R P Herrold wrote:

On Tue, 23 Jan 2018, Daniel P. Berrange wrote:


What needs to be done for this ?  I see my package "libvirt" present
in its UI

   https://apps.fedoraproject.org/koschei/package/libvirt

but it says

   "Package is currently ineligible for scheduling due to following reasons:


looking at the 'EPEL 7' tab, I see:

Base buildroot for EPEL 7 is not installable.

Dependency problems:
nothing provides requested redhat-release-everything

Hunh?



That's a bug in koschei, which will be fixed in the next release.

Michael Simacek


-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 09:17, Neal Gompa wrote:

On Thu, Jan 25, 2018 at 4:13 AM, Richard W.M. Jones  wrote:

On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:

On 25/01/18 08:41, Richard W.M. Jones wrote:

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


Other than detecting cases where shared libraries were missing
NEEDED entries for other shared objects that they use?


I can't remember now what it's called but there's another way to do
that which all other distros except Fedora use.



-Wl,--as-needed and -Wl,--no-undefined

c.f.: http://gitweb.mageia.org/software/rpm/rpm-setup/tree/build.macros.in#n221

openSUSE uses the same approach, but apparently the file doesn't
render on their VCS due to not being UTF-8. :/


But --no-undefined is a synonym for -z defs! They are literally listed 
together in the ld manual page.


The --as-needed varies the algorithm for which shared libraries to mark
as dependencies but doesn't change the behaviour for undefined symbols
as far as I can see.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Thu, Jan 25, 2018 at 4:13 AM, Richard W.M. Jones  wrote:
> On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:
>> On 25/01/18 08:41, Richard W.M. Jones wrote:
>> >On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
>> >>Le 22/01/2018 à 16:24, Florian Weimer a écrit :
>> >>>I updated redhat-rpm-config to instruct ld to reject linking shared
>> >>>objects with undefined symbols.  Such undefined symbols break symbol
>> >>>versioning because the are not necessarily bound to the correct symbol
>> >>>version at run time.  (rhbz#1535422)
>> >>
>> >>So this break all the PHP stack build...
>> >>
>> >>(all php extensions are dl open plugins, relying on symbol from the engine)
>> >
>> >I think the -z defs change should be reverted.  It breaks very long-
>> >standing expected behaviour of linkers and there's been no proper
>> >justification for doing it.
>>
>> Other than detecting cases where shared libraries were missing
>> NEEDED entries for other shared objects that they use?
>
> I can't remember now what it's called but there's another way to do
> that which all other distros except Fedora use.
>

-Wl,--as-needed and -Wl,--no-undefined

c.f.: http://gitweb.mageia.org/software/rpm/rpm-setup/tree/build.macros.in#n221

openSUSE uses the same approach, but apparently the file doesn't
render on their VCS due to not being UTF-8. :/



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Thu, Jan 25, 2018 at 09:03:34AM +, Tom Hughes wrote:
> On 25/01/18 08:41, Richard W.M. Jones wrote:
> >On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
> >>Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> >>>I updated redhat-rpm-config to instruct ld to reject linking shared
> >>>objects with undefined symbols.  Such undefined symbols break symbol
> >>>versioning because the are not necessarily bound to the correct symbol
> >>>version at run time.  (rhbz#1535422)
> >>
> >>So this break all the PHP stack build...
> >>
> >>(all php extensions are dl open plugins, relying on symbol from the engine)
> >
> >I think the -z defs change should be reverted.  It breaks very long-
> >standing expected behaviour of linkers and there's been no proper
> >justification for doing it.
> 
> Other than detecting cases where shared libraries were missing
> NEEDED entries for other shared objects that they use?

I can't remember now what it's called but there's another way to do
that which all other distros except Fedora use.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 08:41, Richard W.M. Jones wrote:

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.


Other than detecting cases where shared libraries were missing NEEDED 
entries for other shared objects that they use?


It found one of those in my packages certainly.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Thu, Jan 25, 2018 at 08:31:29AM +0100, Remi Collet wrote:
> Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> > I updated redhat-rpm-config to instruct ld to reject linking shared
> > objects with undefined symbols.  Such undefined symbols break symbol
> > versioning because the are not necessarily bound to the correct symbol
> > version at run time.  (rhbz#1535422)
> 
> So this break all the PHP stack build...
> 
> (all php extensions are dl open plugins, relying on symbol from the engine)

I think the -z defs change should be reverted.  It breaks very long-
standing expected behaviour of linkers and there's been no proper
justification for doing it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Tom Hughes]

On 25/01/18 07:31, Remi Collet wrote:

Le 22/01/2018 à 16:24, Florian Weimer a écrit :

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols.  Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time.  (rhbz#1535422)


So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


Yes it broke all the nodejs binary modules as well, so I fixed them.

Doubtless it will do the same for perl, ruby, python, etc.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Remi Collet]

Le 22/01/2018 à 16:24, Florian Weimer a écrit :
> I updated redhat-rpm-config to instruct ld to reject linking shared
> objects with undefined symbols.  Such undefined symbols break symbol
> versioning because the are not necessarily bound to the correct symbol
> version at run time.  (rhbz#1535422)

So this break all the PHP stack build...

(all php extensions are dl open plugins, relying on symbol from the engine)


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Vít Ondruch]

Dne 23.1.2018 v 19:03 Daniel P. Berrange napsal(a):
> On Tue, Jan 23, 2018 at 05:56:47PM +, Jonathan Wakely wrote:
>> On 23/01/18 15:38 +0100, Florian Weimer wrote:
>>> We could deactivate -z defs for F28 and reactivate it after the branch
>>> for F29, giving packagers more time to fix issues.
>> I think that might be a good idea (given how late in the F28 process
>> we are) but for many packages it will just mean we have the same
>> problem at the next mass rebuild.
>>
>> Lots of packages don't get rebuilt between releases, so the
>> maintainers won't see any failure for F29 after -z defs becomes the
>> default again, so they won't fix anything.
>>
>> Every package known to have problems now should get added to koschei.
> What needs to be done for this ?  I see my package "libvirt" present
> in its UI
>
>   https://apps.fedoraproject.org/koschei/package/libvirt
>
> but it says
>
>   "Package is currently ineligible for scheduling due to following reasons:
>
> Package is not tracked
> Package dependencies were not resolved yet"
>
> but there's no info about what these reasons really mean, nor how I
> would go about resolving them.

You probably want to go here:

https://apps.fedoraproject.org/koschei/add-packages

And add your packages.

If you want to add the into group, then you want to create the group
prior adding the packages via this link:

https://apps.fedoraproject.org/koschei/add-group


V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 02:06:15PM -0500, R P Herrold wrote:
> On Tue, 23 Jan 2018, Daniel P. Berrange wrote:
> 
> > What needs to be done for this ?  I see my package "libvirt" present
> > in its UI
> > 
> >   https://apps.fedoraproject.org/koschei/package/libvirt
> > 
> > but it says
> > 
> >   "Package is currently ineligible for scheduling due to following reasons:
> 
> looking at the 'EPEL 7' tab, I see:
> 
>   Base buildroot for EPEL 7 is not installable. 
> 
> Dependency problems:
> nothing provides requested redhat-release-everything

EPEL is irrelevant for libvirt as it is shipped in base RHEL/CentOS, so
I've never touched anything related to EPEL branches. THe problems I
mention above were listed when I view the rawhide tab.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[R P Herrold]

On Tue, 23 Jan 2018, Daniel P. Berrange wrote:

> What needs to be done for this ?  I see my package "libvirt" present
> in its UI
> 
>   https://apps.fedoraproject.org/koschei/package/libvirt
> 
> but it says
> 
>   "Package is currently ineligible for scheduling due to following reasons:

looking at the 'EPEL 7' tab, I see:

Base buildroot for EPEL 7 is not installable. 

Dependency problems:
nothing provides requested redhat-release-everything

Hunh?  

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 05:56:47PM +, Jonathan Wakely wrote:
> On 23/01/18 15:38 +0100, Florian Weimer wrote:
> > We could deactivate -z defs for F28 and reactivate it after the branch
> > for F29, giving packagers more time to fix issues.
> 
> I think that might be a good idea (given how late in the F28 process
> we are) but for many packages it will just mean we have the same
> problem at the next mass rebuild.
> 
> Lots of packages don't get rebuilt between releases, so the
> maintainers won't see any failure for F29 after -z defs becomes the
> default again, so they won't fix anything.
> 
> Every package known to have problems now should get added to koschei.

What needs to be done for this ?  I see my package "libvirt" present
in its UI

  https://apps.fedoraproject.org/koschei/package/libvirt

but it says

  "Package is currently ineligible for scheduling due to following reasons:

Package is not tracked
Package dependencies were not resolved yet"

but there's no info about what these reasons really mean, nor how I
would go about resolving them.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Jonathan Wakely]

On 23/01/18 15:38 +0100, Florian Weimer wrote:
We could deactivate -z defs for F28 and reactivate it after the branch 
for F29, giving packagers more time to fix issues.


I think that might be a good idea (given how late in the F28 process
we are) but for many packages it will just mean we have the same
problem at the next mass rebuild.

Lots of packages don't get rebuilt between releases, so the
maintainers won't see any failure for F29 after -z defs becomes the
default again, so they won't fix anything.

Every package known to have problems now should get added to koschei.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/23/2018 12:26 PM, Mamoru TASAKA wrote:

Florian Weimer wrote on 01/23/2018 12:24 AM:


In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.  In this case, you can
add

 %undefine _strict_symbol_defs_build

to the RPM spec file to disable these strict checks. 


So this seems to affect lots of packages containing
/usr/lib64/foo/libbar.so. At least my packages

- cairo-dock


It's not clear whether this isn't rather a package bug.  Many symbols 
could come from -lgldi as well, but some of them are defined by 
/usr/bin/cairo-dock as well.  However, that program has a DT_NEEDED 
entry for libgldi.so.3, so it is unclear what is going on.


Have you tried adding the missing -l arguments?


- cairo-dock-plug-ins


(not checked)


- gnome-commander


This has a plugin-style reference for main_win_widget (which is only 
defined in /usr/libexec/gnome-commander/gnome-commander), but failures 
further down are to a missing -lgcmd.  Definitely a mixed bag.



failed to build due to this, and at least
- dia


Looks like a missing -lglib-2.0, so it's a package bug.


- sssd


Looks like a package bug, probably a missing -lsss_util.  (Although it 
is not entirely clear which sssd shared object contains the canonical 
definition of each function.)



- ModemManager


This is a true plug-in case, so it needs to avoid to build with -z defs 
(which will obscure the missing -lglib-2.0, which should nevertheless be 
added).



- pidgin


Looks like a missing -lpurple -lpthread -lglib-2.0, probably more. 
(/usr/sbin/bitlbee defines some purple_* symbols, but I don't know if 
any of the compiled DSOs are in fact plug-ins for that program.  If not, 
it should be possible to get the whole thing to link with -z defs.)


So the majority of these issues are package bugs.  This is not entirely 
what I expected—in an ideal world, the impact would have been restricted 
to true plug-ins.  Some of the existing linking issues aren't entirely 
harmless and can cause problems today or further down the road (because 
the dependency information on various layers is incorrect).


We could deactivate -z defs for F28 and reactivate it after the branch 
for F29, giving packagers more time to fix issues.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 02:04:26PM +0100, Florian Weimer wrote:
> On 01/23/2018 01:49 PM, Daniel P. Berrange wrote:
> > On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> > > I updated redhat-rpm-config to instruct ld to reject linking shared 
> > > objects
> > > with undefined symbols.  Such undefined symbols break symbol versioning
> > > because the are not necessarily bound to the correct symbol version at run
> > > time.  (rhbz#1535422)
> > > 
> > > ### Disable strict symbol checks in the link editor (ld)
> > > 
> > > By default, the link editor will refuse to link shared objects which
> > > contain undefined symbols.  In some cases (such as when a DSO is
> > > loaded as a plugin and is expected to bind to symbols in the main
> > > executable), undefined symbols are expected.  In this case, you can
> > > add
> > > 
> > >  %undefine _strict_symbol_defs_build
> > > 
> > > to the RPM spec file to disable these strict checks.  Alternatively,
> > > you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> > > command line).  The latter needs binutils 2.29.1-12.fc28 or later.
> > 
> > This affects libvirt, because we have a tonne of dlopen()able modules
> > which have undefined symbols that get resolved against the binary
> > that's loading them:
> > 
> >https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log
> > 
> > I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
> > spec for now.
> 
> Some of these symbols are also defined in libvirt.so.0.  In fact, in the
> link failure above, I don't see a *single* symbol which isn't defined in
> libvirt.so.0.  And /usr/sbin/libvirtd has a DT_NEEDED entry for libvirt.so.0
> anyway, so it's not actually about loading libvirt.so.0.
> 
> This looks more like the new style of doing plug-ins, where the shared code
> is in a separate DSO which is linked from both the main application and the
> plug-ins.  In this case, maybe you can complete the transition and avoid
> quite a bit of duplicate by removing the definitions from the main program?

The stuff the modules depend on is probably all in libvirt.so, but
I'm not 100% that's the case for all our modules - the build failure
above stopped the build before getting onto many of our other modules.

I'll have a go at explicitly linking the plugins with libvirt.so upstream
though, to see if that's sufficient to kee the linker happy, and if so
add '-z defs' by default to upstream's build.

> If there is deliberate symbol interposition going on to alter the
> functionality of libvirt.so.0, then this will continue to work even if the
> plug-ins are linked explicitly against libvirt.so.0.

I don't think we do symbol interposition

> > I wonder if you can elaborate on what we should look out for wrt the
> > glibc vs tirpc symbol resolution problem mentioned.  libvirt uses
> > XDR APIs, so is potentially affected by this. In rawhide, we are
> > linking with an explicit "-ltirpc" line already though. Is that
> > enough to avoid the problems you describe wrt xdr_* symbols getting
> > incorrectly resolved ?
> 
> The xdr_* symbols should have TIRPC_* symbol version.  Then you are good.

Ok, thanks.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/23/2018 01:49 PM, Daniel P. Berrange wrote:

On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:

I updated redhat-rpm-config to instruct ld to reject linking shared objects
with undefined symbols.  Such undefined symbols break symbol versioning
because the are not necessarily bound to the correct symbol version at run
time.  (rhbz#1535422)

### Disable strict symbol checks in the link editor (ld)

By default, the link editor will refuse to link shared objects which
contain undefined symbols.  In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.  In this case, you can
add

 %undefine _strict_symbol_defs_build

to the RPM spec file to disable these strict checks.  Alternatively,
you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
command line).  The latter needs binutils 2.29.1-12.fc28 or later.


This affects libvirt, because we have a tonne of dlopen()able modules
which have undefined symbols that get resolved against the binary
that's loading them:

   https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log

I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
spec for now.


Some of these symbols are also defined in libvirt.so.0.  In fact, in the 
link failure above, I don't see a *single* symbol which isn't defined in 
libvirt.so.0.  And /usr/sbin/libvirtd has a DT_NEEDED entry for 
libvirt.so.0 anyway, so it's not actually about loading libvirt.so.0.


This looks more like the new style of doing plug-ins, where the shared 
code is in a separate DSO which is linked from both the main application 
and the plug-ins.  In this case, maybe you can complete the transition 
and avoid quite a bit of duplicate by removing the definitions from the 
main program?


If there is deliberate symbol interposition going on to alter the 
functionality of libvirt.so.0, then this will continue to work even if 
the plug-ins are linked explicitly against libvirt.so.0.



I wonder if you can elaborate on what we should look out for wrt the
glibc vs tirpc symbol resolution problem mentioned.  libvirt uses
XDR APIs, so is potentially affected by this. In rawhide, we are
linking with an explicit "-ltirpc" line already though. Is that
enough to avoid the problems you describe wrt xdr_* symbols getting
incorrectly resolved ?


The xdr_* symbols should have TIRPC_* symbol version.  Then you are good.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared objects
> with undefined symbols.  Such undefined symbols break symbol versioning
> because the are not necessarily bound to the correct symbol version at run
> time.  (rhbz#1535422)
> 
> ### Disable strict symbol checks in the link editor (ld)
> 
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols.  In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected.  In this case, you can
> add
> 
> %undefine _strict_symbol_defs_build
> 
> to the RPM spec file to disable these strict checks.  Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line).  The latter needs binutils 2.29.1-12.fc28 or later.

This affects libvirt, because we have a tonne of dlopen()able modules
which have undefined symbols that get resolved against the binary
that's loading them:

  https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log

I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
spec for now.

I wonder if you can elaborate on what we should look out for wrt the
glibc vs tirpc symbol resolution problem mentioned.  libvirt uses
XDR APIs, so is potentially affected by this. In rawhide, we are
linking with an explicit "-ltirpc" line already though. Is that
enough to avoid the problems you describe wrt xdr_* symbols getting
incorrectly resolved ?

We could potentially explore a change to our build system upstream
so add  "-z defs" only to libvirt.so (which uses the xdr_* APIs)
but *not* the loadable modules. IIUC, that would protect us for
the symbol resolution without triggered the undefined symbols
problem in other parts of our code.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/23/2018 10:25 AM, Fabio Valentini wrote:

For the record, my affected packages are (according to koschei, and as
of the time of writing this):
- gala (internal plugins)
- maya-calendar("ceil" reference missing, ppc64 only)


So it's a missing -lm on the linker command line.


- noise (internal plugins)


This is a classic plugin case.


- scratch-text-editor(internal plugins)


This is a bit tricky.  Looks like the code is duplicated between the 
main program and a shared object.  We stopped doing that for 
Python/Perl/Lua …



- slingshot-launcher(plugin)


Have you fixed the powf undefined symbol, and it still fails?


- switchboard-plug-onlineaccounts(internal plugins)


This looks like an actual package bug, -lpantheon-online-accounts is 
missing.  As far as I can tell, no executable provides these symbols, so 
the library is really needed at run time.



- wingpanel(no idea)


Missing -lm.


- wingpanel-indicator-datetime ("ceil" reference missing, ppc64 only)


Same problem.

While some of the failures you listed are genuine plugins, about as many 
actually prevent the creation of incorrectly linked shared objects.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Mamoru TASAKA]

Florian Weimer wrote on 01/23/2018 12:24 AM:


In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.  In this case, you can
add

     %undefine _strict_symbol_defs_build

to the RPM spec file to disable these strict checks.  


So this seems to affect lots of packages containing
/usr/lib64/foo/libbar.so. At least my packages

- cairo-dock
- cairo-dock-plug-ins
- gnome-commander

failed to build due to this, and at least
- dia
- sssd
- ModemManager
- pidgin

now also fail to build (I chose the above packages randomly - so not a
complete list).
Are these all packages have to modify? At least this change should have been
announced more formally and explicitly as system-wide-change.

Regards,
Mamor
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 23 January 2018 at 11:28, Dominik 'Rathann' Mierzejewski wrote:
> Hi, Florian.
> 
> On Monday, 22 January 2018 at 16:24, Florian Weimer wrote:
> > I updated redhat-rpm-config to instruct ld to reject linking shared objects
> > with undefined symbols.  Such undefined symbols break symbol versioning
> > because the are not necessarily bound to the correct symbol version at run
> > time.  (rhbz#1535422)
> 
> Where's the System Wide Change for F28 for this? I can only see
> https://fedoraproject.org/wiki/Changes/HardeningFlags28 on the list
> (https://fedoraproject.org/wiki/Releases/28/ChangeSet). It doesn't
> mention adding "-z defs". Please revert this as soon as possible.

Sorry, just found out it's part of
https://fedoraproject.org/wiki/Changes/BINUTILS2291 . The Change is
misnamed, as the only important thing is the linker flags change.
Please rename it.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

On 01/23/2018 11:28 AM, Dominik 'Rathann' Mierzejewski wrote:

Hi, Florian.

On Monday, 22 January 2018 at 16:24, Florian Weimer wrote:

I updated redhat-rpm-config to instruct ld to reject linking shared objects
with undefined symbols.  Such undefined symbols break symbol versioning
because the are not necessarily bound to the correct symbol version at run
time.  (rhbz#1535422)


Where's the System Wide Change for F28 for this? I can only see
https://fedoraproject.org/wiki/Changes/HardeningFlags28 on the list
(https://fedoraproject.org/wiki/Releases/28/ChangeSet). It doesn't
mention adding "-z defs". Please revert this as soon as possible.


It is mentioned in the binutils change:

  https://fedoraproject.org/wiki/Changes/BINUTILS2291

I also mentioned the change when it was suggested that the binutils 
change did not need to be system-wide.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Dominik 'Rathann' Mierzejewski]

Hi, Florian.

On Monday, 22 January 2018 at 16:24, Florian Weimer wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared objects
> with undefined symbols.  Such undefined symbols break symbol versioning
> because the are not necessarily bound to the correct symbol version at run
> time.  (rhbz#1535422)

Where's the System Wide Change for F28 for this? I can only see
https://fedoraproject.org/wiki/Changes/HardeningFlags28 on the list
(https://fedoraproject.org/wiki/Releases/28/ChangeSet). It doesn't
mention adding "-z defs". Please revert this as soon as possible.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Fabio Valentini]

On Mon, Jan 22, 2018 at 4:24 PM, Florian Weimer  wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared objects
> with undefined symbols.  Such undefined symbols break symbol versioning
> because the are not necessarily bound to the correct symbol version at run
> time.  (rhbz#1535422)
>
> ### Disable strict symbol checks in the link editor (ld)
>
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols.  In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected.  In this case, you can
> add
>
> %undefine _strict_symbol_defs_build
>
> to the RPM spec file to disable these strict checks.  Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line).  The latter needs binutils 2.29.1-12.fc28 or later.

So, with this change to redhat-rpm-config, about 20 of my ~100
packages now fail / will probably fail to build due to undefined
symbols.

For the record, my affected packages are (according to koschei, and as
of the time of writing this):
- gala (internal plugins)
- maya-calendar("ceil" reference missing, ppc64 only)
- noise (internal plugins)
- pantheon-photos(internal plugins)
- scratch-text-editor(internal plugins)
- slingshot-launcher(plugin)
- switchboard-plug-onlineaccounts(internal plugins)
- wingpanel(no idea)
- wingpanel-indicator-datetime ("ceil" reference missing, ppc64 only)

I have no idea how to tell if these are really fallout from the change
to redhat-rpm-config, or if the change only uncovered bugs in the
upstream build definitions (which lead to erroneous underlinking?).

Fabio

> This is also part of the build flags documentation at:
>
> 
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard W.M. Jones]

On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared
> objects with undefined symbols.  Such undefined symbols break symbol
> versioning because the are not necessarily bound to the correct
> symbol version at run time.  (rhbz#1535422)

This seems like a very invasive change.  I maintain a few projects
where undefined symbols in DSOs are a necessary and expected thing,
and I don't think I should need to set a flag to get them to compile.

In the bug the only justification for this change is:

  "This is very desirable for the Sun RPC removal, otherwise programs
  continue to build by accident."

Can you explain why programs will continue to build now that glibc has
removed xdr_* etc symbols?  In all the programs I have tried to build
which used SunRPC, none of them continued to build.  All required
explicit changes (eg. changing configure to detect libtirpc, adding
new linker flags).

> ### Disable strict symbol checks in the link editor (ld)
> 
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols.  In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected.  In this case, you can
> add
> 
> %undefine _strict_symbol_defs_build
> 
> to the RPM spec file to disable these strict checks.  Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line).  The latter needs binutils 2.29.1-12.fc28 or later.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org