Re: libtool and LDFLAGS build flags injection

2018-02-23 Thread Philip Kovacs 
The package is slurm and the issue is their plugins.  It's a deep architectural 
problem unfortunately,To summarize the issue briefly:  When designing a plugin 
system, the services a plugin providesought not depend on the environment that 
loads it.  That is not the case for slurm.   Their pluginscontain symbols that 
refer back to the program that loads them. 
Suppose you have a plugin P loaded by programs A and B.   Slurm's plugins often 
contain symbols a in A and b in B.  When program A loads plugin P, the symbols 
b remain unresolved.  When program B loads plugin P, the symbols a remain 
unresolved.
I have spent hours supplying complex patches for them to "harden" and meet the 
bind now requirement,They acknowledge the problem but do not have enough 
customers complaining about it yet.  Slurm issoftware deployed in large HPC 
research centers typically (hundred, thousands or more nodes). 
 

On Friday, February 23, 2018 12:26 PM, John Reiser  
wrote:
 

 Philip Kovacs wrote:
> My particular concern is not "missing" bind now flags in the elf objects.  I 
> am concerned about
> making sure bind now is omitted because the package cannot operate with that 
> flag.

Please tell us the name of the packages, and some indication of why
the package does not work with BIND_NOW.  Having specific information
might help to identify and understand a more-general situation.
___
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: libtool and LDFLAGS build flags injection

2018-02-23 Thread John Reiser 

Philip Kovacs wrote:

My particular concern is not "missing" bind now flags in the elf objects.  I am 
concerned about
making sure bind now is omitted because the package cannot operate with that 
flag.


Please tell us the name of the packages, and some indication of why
the package does not work with BIND_NOW.  Having specific information
might help to identify and understand a more-general situation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

2018-02-23 Thread Philip Kovacs 
My particular concern is not "missing" bind now flags in the elf objects.  I am 
concerned aboutmaking sure bind now is omitted because the package cannot 
operate with that flag. 

On Friday, February 23, 2018 11:35 AM, Florian Weimer  
wrote:
 

 On 02/23/2018 05:16 PM, Philip Kovacs wrote:
> The bind now issue is a real problem for some packages.  I have interacted 
> with upstream countlesstimes on it and simply lost the fight.  Please, 
> whatever you do, leave some route to disable bind now.

Disable it for what?

The vast majority of missing BIND_NOW flags has been caused by 
accidentally dropped LDFLAGS settings.  (That, and firmware files which 
happen to be ELF.)

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: libtool and LDFLAGS build flags injection

2018-02-23 Thread Florian Weimer 

On 02/23/2018 05:16 PM, Philip Kovacs wrote:

The bind now issue is a real problem for some packages.  I have interacted with 
upstream countlesstimes on it and simply lost the fight.  Please, whatever you 
do, leave some route to disable bind now.


Disable it for what?

The vast majority of missing BIND_NOW flags has been caused by 
accidentally dropped LDFLAGS settings.  (That, and firmware files which 
happen to be ELF.)


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

Re: libtool and LDFLAGS build flags injection

2018-02-23 Thread Philip Kovacs 
The bind now issue is a real problem for some packages.  I have interacted with 
upstream countlesstimes on it and simply lost the fight.  Please, whatever you 
do, leave some route to disable bind now. 

On Friday, February 23, 2018 10:55 AM, Florian Weimer  
wrote:
 

 I've seen a fair amount of LDFLAGS injection failures related to 
libtool.  For the most part, 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a 
lack of BIND_NOW in the resulting binary.

Is there a way we can fix this in libtool or the auto* tools?  I'm also 
considering moving -Wl,-z,now to the command line from the GCC specs 
file, which might help here, too.  But I'd prefer a direct, unfiltered 
channel from redhat-rpm-config to the linker invocation in case we need 
to inject additional flags.

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

libtool and LDFLAGS build flags injection

2018-02-23 Thread Florian Weimer 
I've seen a fair amount of LDFLAGS injection failures related to 
libtool.  For the most part, 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a 
lack of BIND_NOW in the resulting binary.


Is there a way we can fix this in libtool or the auto* tools?  I'm also 
considering moving -Wl,-z,now to the command line from the GCC specs 
file, which might help here, too.  But I'd prefer a direct, unfiltered 
channel from redhat-rpm-config to the linker invocation in case we need 
to inject additional flags.


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