[PATCH] Add implicit lib requirements to LDLIBS

[PATCH] Add implicit lib requirements to LDLIBS

[Joshua Brindle]

Fedora 13 changed their linker behavior to not link indirect libraries.
See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

Resent, it doesn't look like it made it to the list the first time (and the subject had a typo)

Signed-off-by: Joshua Brindle <jbrindle@tresys.com>
---
 policycoreutils/semodule/Makefile  |    2 +-
 policycoreutils/setsebool/Makefile |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/policycoreutils/semodule/Makefile b/policycoreutils/semodule/Makefile
index c96a286..a0bbc21 100644
--- a/policycoreutils/semodule/Makefile
+++ b/policycoreutils/semodule/Makefile
@@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
 
 CFLAGS ?= -Werror -Wall -W
 override CFLAGS += -I$(INCLUDEDIR)
-LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
+LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR) 
 SEMODULE_OBJS = semodule.o
 
 all: semodule
diff --git a/policycoreutils/setsebool/Makefile b/policycoreutils/setsebool/Makefile
index 556b780..1b89d5c 100644
--- a/policycoreutils/setsebool/Makefile
+++ b/policycoreutils/setsebool/Makefile
@@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
 
 CFLAGS ?= -Werror -Wall -W
 override CFLAGS += -I$(INCLUDEDIR)
-LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
+LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR)
 SETSEBOOL_OBJS = setsebool.o
 
 all: setsebool
-- 
1.7.0.1


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Eamon Walsh]

On 03/30/2010 05:08 PM, Joshua Brindle wrote:
> Fedora 13 changed their linker behavior to not link indirect libraries.
> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>   

I skimmed over semodule.c and setsebool.c and I didn't see any
references to bzip2 or ustr symbols.  My reading of the article suggests
the below fix should only be needed if that were the case.  Most likely
I missed them?

Without this patch, do you get the linker error that says to add them?



> Resent, it doesn't look like it made it to the list the first time (and the subject had a typo)
>
> Signed-off-by: Joshua Brindle <jbrindle@tresys.com>
> ---
>  policycoreutils/semodule/Makefile  |    2 +-
>  policycoreutils/setsebool/Makefile |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/policycoreutils/semodule/Makefile b/policycoreutils/semodule/Makefile
> index c96a286..a0bbc21 100644
> --- a/policycoreutils/semodule/Makefile
> +++ b/policycoreutils/semodule/Makefile
> @@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
>  
>  CFLAGS ?= -Werror -Wall -W
>  override CFLAGS += -I$(INCLUDEDIR)
> -LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
> +LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR) 
>  SEMODULE_OBJS = semodule.o
>  
>  all: semodule
> diff --git a/policycoreutils/setsebool/Makefile b/policycoreutils/setsebool/Makefile
> index 556b780..1b89d5c 100644
> --- a/policycoreutils/setsebool/Makefile
> +++ b/policycoreutils/setsebool/Makefile
> @@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
>  
>  CFLAGS ?= -Werror -Wall -W
>  override CFLAGS += -I$(INCLUDEDIR)
> -LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
> +LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR)
>  SETSEBOOL_OBJS = setsebool.o
>  
>  all: setsebool
>   


-- 

Eamon Walsh 
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Joshua Brindle]

Eamon Walsh wrote:
> On 03/30/2010 05:08 PM, Joshua Brindle wrote:
>> Fedora 13 changed their linker behavior to not link indirect libraries.
>> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>>
>
> I skimmed over semodule.c and setsebool.c and I didn't see any
> references to bzip2 or ustr symbols.  My reading of the article suggests
> the below fix should only be needed if that were the case.  Most likely
> I missed them?
>

The link above is confusing. The change was made so that people who 
_did_ use eg., libxml but didn't explicitly link against it would have 
to do so even if other libraries they link against already did.

In our case it means that anything libsemanage needs semodule and 
setsebool will also need to link against explicitly.

Here is another page about the "feature":
http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking

The summary pretty much covers it I think:
""Change DSO-linking semantics of the gcc compiler. Previously calls to 
the linker (ld) from gcc would result in dangerous default behaviour 
where ld would attempt to implicitly satisfy link requirements. The 
proposed change will prevent ld from automatically searching in the 
dependencies of linked objects.""

> Without this patch, do you get the linker error that says to add them?
>

Yes. It complains about missing bz2 and ustr symbols on my F13 system.

>
>
>> Resent, it doesn't look like it made it to the list the first time (and the subject had a typo)
>>
>> Signed-off-by: Joshua Brindle<jbrindle@tresys.com>
>> ---
>>   policycoreutils/semodule/Makefile  |    2 +-
>>   policycoreutils/setsebool/Makefile |    2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/policycoreutils/semodule/Makefile b/policycoreutils/semodule/Makefile
>> index c96a286..a0bbc21 100644
>> --- a/policycoreutils/semodule/Makefile
>> +++ b/policycoreutils/semodule/Makefile
>> @@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
>>
>>   CFLAGS ?= -Werror -Wall -W
>>   override CFLAGS += -I$(INCLUDEDIR)
>> -LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
>> +LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR)
>>   SEMODULE_OBJS = semodule.o
>>
>>   all: semodule
>> diff --git a/policycoreutils/setsebool/Makefile b/policycoreutils/setsebool/Makefile
>> index 556b780..1b89d5c 100644
>> --- a/policycoreutils/setsebool/Makefile
>> +++ b/policycoreutils/setsebool/Makefile
>> @@ -7,7 +7,7 @@ LIBDIR ?= ${PREFIX}/lib
>>
>>   CFLAGS ?= -Werror -Wall -W
>>   override CFLAGS += -I$(INCLUDEDIR)
>> -LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
>> +LDLIBS = -lsepol -lselinux -lsemanage -lbz2 -lustr -L$(LIBDIR)
>>   SETSEBOOL_OBJS = setsebool.o
>>
>>   all: setsebool
>>
>
>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Stephen Smalley]

On Wed, 2010-03-31 at 09:21 -0400, Joshua Brindle wrote:
> Eamon Walsh wrote:
> > On 03/30/2010 05:08 PM, Joshua Brindle wrote:
> >> Fedora 13 changed their linker behavior to not link indirect libraries.
> >> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
> >>
> >
> > I skimmed over semodule.c and setsebool.c and I didn't see any
> > references to bzip2 or ustr symbols.  My reading of the article suggests
> > the below fix should only be needed if that were the case.  Most likely
> > I missed them?
> >
> 
> The link above is confusing. The change was made so that people who 
> _did_ use eg., libxml but didn't explicitly link against it would have 
> to do so even if other libraries they link against already did.
> 
> In our case it means that anything libsemanage needs semodule and 
> setsebool will also need to link against explicitly.
> 
> Here is another page about the "feature":
> http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
> 
> The summary pretty much covers it I think:
> ""Change DSO-linking semantics of the gcc compiler. Previously calls to 
> the linker (ld) from gcc would result in dangerous default behaviour 
> where ld would attempt to implicitly satisfy link requirements. The 
> proposed change will prevent ld from automatically searching in the 
> dependencies of linked objects.""
> 
> > Without this patch, do you get the linker error that says to add them?
> >
> 
> Yes. It complains about missing bz2 and ustr symbols on my F13 system.

This doesn't seem right to me either, and I don't quite understand why
Dan wouldn't have encountered it already if it was an issue.

As I read it, the change in behavior should only affect the program if
the program makes calls to symbols in the library and was previously
implicitly getting a dependency through another library.  But if the
program makes no calls to the library in question, it shouldn't need to
link against it.

I think something is wrong with the way we are building libsemanage.
Maybe this has something to do with our use of -z,defs there.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Stephen Smalley]

On Wed, 2010-03-31 at 11:15 -0400, Stephen Smalley wrote:
> On Wed, 2010-03-31 at 09:21 -0400, Joshua Brindle wrote:
> > Eamon Walsh wrote:
> > > On 03/30/2010 05:08 PM, Joshua Brindle wrote:
> > >> Fedora 13 changed their linker behavior to not link indirect libraries.
> > >> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
> > >>
> > >
> > > I skimmed over semodule.c and setsebool.c and I didn't see any
> > > references to bzip2 or ustr symbols.  My reading of the article suggests
> > > the below fix should only be needed if that were the case.  Most likely
> > > I missed them?
> > >
> > 
> > The link above is confusing. The change was made so that people who 
> > _did_ use eg., libxml but didn't explicitly link against it would have 
> > to do so even if other libraries they link against already did.
> > 
> > In our case it means that anything libsemanage needs semodule and 
> > setsebool will also need to link against explicitly.
> > 
> > Here is another page about the "feature":
> > http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
> > 
> > The summary pretty much covers it I think:
> > ""Change DSO-linking semantics of the gcc compiler. Previously calls to 
> > the linker (ld) from gcc would result in dangerous default behaviour 
> > where ld would attempt to implicitly satisfy link requirements. The 
> > proposed change will prevent ld from automatically searching in the 
> > dependencies of linked objects.""
> > 
> > > Without this patch, do you get the linker error that says to add them?
> > >
> > 
> > Yes. It complains about missing bz2 and ustr symbols on my F13 system.
> 
> This doesn't seem right to me either, and I don't quite understand why
> Dan wouldn't have encountered it already if it was an issue.
> 
> As I read it, the change in behavior should only affect the program if
> the program makes calls to symbols in the library and was previously
> implicitly getting a dependency through another library.  But if the
> program makes no calls to the library in question, it shouldn't need to
> link against it.

See:
http://lists.fedoraproject.org/pipermail/devel/2010-January/129131.html

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2010-03-31 at 11:15 -0400, Stephen Smalley wrote:
>> On Wed, 2010-03-31 at 09:21 -0400, Joshua Brindle wrote:
>>> Eamon Walsh wrote:
>>>> On 03/30/2010 05:08 PM, Joshua Brindle wrote:
>>>>> Fedora 13 changed their linker behavior to not link indirect libraries.
>>>>> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>>>>>
>>>> I skimmed over semodule.c and setsebool.c and I didn't see any
>>>> references to bzip2 or ustr symbols.  My reading of the article suggests
>>>> the below fix should only be needed if that were the case.  Most likely
>>>> I missed them?
>>>>
>>> The link above is confusing. The change was made so that people who
>>> _did_ use eg., libxml but didn't explicitly link against it would have
>>> to do so even if other libraries they link against already did.
>>>
>>> In our case it means that anything libsemanage needs semodule and
>>> setsebool will also need to link against explicitly.
>>>
>>> Here is another page about the "feature":
>>> http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>>>
>>> The summary pretty much covers it I think:
>>> ""Change DSO-linking semantics of the gcc compiler. Previously calls to
>>> the linker (ld) from gcc would result in dangerous default behaviour
>>> where ld would attempt to implicitly satisfy link requirements. The
>>> proposed change will prevent ld from automatically searching in the
>>> dependencies of linked objects.""
>>>
>>>> Without this patch, do you get the linker error that says to add them?
>>>>
>>> Yes. It complains about missing bz2 and ustr symbols on my F13 system.
>> This doesn't seem right to me either, and I don't quite understand why
>> Dan wouldn't have encountered it already if it was an issue.
>>
>> As I read it, the change in behavior should only affect the program if
>> the program makes calls to symbols in the library and was previously
>> implicitly getting a dependency through another library.  But if the
>> program makes no calls to the library in question, it shouldn't need to
>> link against it.
>
> See:
> http://lists.fedoraproject.org/pipermail/devel/2010-January/129131.html
>

Bug it may be but I can't build on F13 right now without these changes. 
I suppose I'll keep them local until something is fixed.

On another note I also see this on F13:

cc -Wall -W -Wundef -Wshadow -Wmissing-noreturn 
-Wmissing-format-attribute -Wno-unused-parameter -I../include 
-I/home/method/s/usr/include -D_GNU_SOURCE   -shared -o libsemanage.so.1 
boolean_record.lo booleans_active.lo booleans_activedb.lo 
booleans_file.lo booleans_local.lo booleans_policy.lo 
booleans_policydb.lo context_record.lo database_activedb.lo database.lo 
database_file.lo database_join.lo database_llist.lo database_policydb.lo 
debug.lo direct_api.lo fcontext_record.lo fcontexts_file.lo 
fcontexts_local.lo fcontexts_policy.lo genhomedircon.lo handle.lo 
iface_record.lo interfaces_file.lo interfaces_local.lo 
interfaces_policy.lo interfaces_policydb.lo modules.lo node_record.lo 
nodes_file.lo nodes_local.lo nodes_policy.lo nodes_policydb.lo 
parse_utils.lo policy_components.lo port_record.lo ports_file.lo 
ports_local.lo ports_policy.lo ports_policydb.lo semanage_store.lo 
seuser_record.lo seusers_file.lo seusers_local.lo seusers_policy.lo 
user_base_record.lo user_extra_record.lo user_record.lo 
users_base_file.lo users_base_policydb.lo users_extra_file.lo 
users_join.lo users_local.lo users_policy.lo utilities.lo conf-scan.lo 
conf-parse.lo -lsepol -lselinux -lbz2 -lustr -L/home/method/s/lib64 
-Wl,-soname,libsemanage.so.1,--version-script=libsemanage.map,-z,defs
/usr/bin/ld: /home/method/s/lib64/libselinux.a(booleans.o): relocation 
R_X86_64_32 against `.rodata' can not be used when making a shared 
object; recompile with -fPIC
/home/method/s/lib64/libselinux.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

it only happens if I set LIBDIR and SHLIBDIR.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] Add implicit lib requirements to LDLIBS

[Eamon Walsh]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On 03/31/2010 09:21 AM, Joshua Brindle wrote:
> Eamon Walsh wrote:
>   
>> On 03/30/2010 05:08 PM, Joshua Brindle wrote:
>>     
>>> Fedora 13 changed their linker behavior to not link indirect libraries.
>>> See information at: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>>>
>>>       
>> I skimmed over semodule.c and setsebool.c and I didn't see any
>> references to bzip2 or ustr symbols.  My reading of the article suggests
>> the below fix should only be needed if that were the case.  Most likely
>> I missed them?
>>
>>     
> The link above is confusing. The change was made so that people who 
> _did_ use eg., libxml but didn't explicitly link against it would have 
> to do so even if other libraries they link against already did.
>
> In our case it means that anything libsemanage needs semodule and 
> setsebool will also need to link against explicitly.
>   

I'm still not seeing that anywhere in the discussion.  As far as I can
see, libraries are still supposed to pull in their own dependencies. 
Putting -lustr -lbz2 on the program build line should only be necessary
if the program source itself uses them, which semodule doesn't seem to. 
I think something's fishy in our build.

Take the following gtk2 program (attached).  I can successfully build
and run this program on rawhide just by linking with gtk2, even though
gtk2 has a ton of other libraries that it needs:

# gcc -I /usr/include/atk-1.0 -I /usr/include/pango-1.0 -I
/usr/include/cairo -I /usr/include/gtk-2.0 -I /usr/lib/gtk-2.0/include
-I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include -o gtkhelloworld
gtkhelloworld.c -lgtk-x11-2.0
#




-- 

Eamon Walsh 
National Security Agency


[-- Attachment #2: gtkhelloworld.c --]
[-- Type: text/plain, Size: 2102 bytes --]

#include <stdio.h>
#include <gtk/gtk.h>

/* This is a callback function. The data arguments are ignored
 * in this example. More on callbacks below. */
static void hello( GtkWidget *widget,
                   gpointer   data )
{
    printf ("Hello World\n");
}

static gboolean delete_event( GtkWidget *widget,
                              GdkEvent  *event,
                              gpointer   data )
{
    /* If you return FALSE in the "delete_event" signal handler,
     * GTK will emit the "destroy" signal. Returning TRUE means
     * you don't want the window to be destroyed.
     * This is useful for popping up 'are you sure you want to quit?'
     * type dialogs. */

    printf ("delete event occurred\n");

    /* Change TRUE to FALSE and the main window will be destroyed with
     * a "delete_event". */

    return TRUE;
}

/* Another callback */
static void destroy( GtkWidget *widget,
                     gpointer   data )
{
    gtk_main_quit ();
}

int main( int   argc,
          char *argv[] )
{
    /* GtkWidget is the storage type for widgets */
    GtkWidget *window;
    GtkWidget *button;
    
    /* This is called in all GTK applications. Arguments are parsed
     * from the command line and are returned to the application. */
    gtk_init (&argc, &argv);
    
    /* create a new window */
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    /* Sets the border width of the window. */
    gtk_container_set_border_width ((GtkContainer *)window, 10);
    
    /* Creates a new button with the label "Hello World". */
    button = gtk_button_new_with_label ("Hello World");
    
    /* This packs the button into the window (a gtk container). */
    gtk_container_add ((GtkContainer *)window, button);
    
    /* The final step is to display this newly created widget. */
    gtk_widget_show (button);
    
    /* and the window */
    gtk_widget_show (window);
    
    /* All GTK applications must have a gtk_main(). Control ends here
     * and waits for an event to occur (like a key press or
     * mouse event). */
    gtk_main ();
    
    return 0;
}