FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 06-04-2010, 08:22 AM
Michael Schwendt
 
Default binutils once more

The saga "binutils does not adhere to Static Library Packaging Guidelines"
continues.

Temporarily the issue had been fixed, then it has been reverted by adding
"Provides" that violate the guidelines again. When I permitted my checker
script to reopen the bugzilla ticket, it was quickly closed as NOTABUG
this time.

binutils : does not adhere to Static Library Packaging Guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=556040

The ticket that lead to violating the guidelines again:

libbfd.so in binutils-devel needs libbfd.a in binutils-static
https://bugzilla.redhat.com/show_bug.cgi?id=576300

[...]

I'd appreciate if the Fedora Packaging Committee discussed this and either
officially excludes the binutils package from the guidelines or adjusts the
guidelines.

To brief all readers: binutils ships shared *and* static libs, but it
replaces the *.so files used for linking at build-time with ld scripts
that only link statically. It has been said that the library interfaces
are not stable enough to link shared.

$ rpmlsv -p binutils-2.20.51.0.7-3.fc14.i686.rpm | grep /lib
-rwxr-xr-x root root 881172 /usr/lib/libbfd-2.20.51.0.7-3.fc14.so
-rwxr-xr-x root root 561296 /usr/lib/libopcodes-2.20.51.0.7-3.fc14.so

$ rpmlsv -p binutils-static-2.20.51.0.7-3.fc14.i686.rpm|grep /lib
-rw-r--r-- root root 23878 /usr/include/libiberty.h
-rw-r--r-- root root 1104328 /usr/lib/libbfd.a
-rw-r--r-- root root 271 /usr/lib/libbfd.so
-rw-r--r-- root root 274322 /usr/lib/libiberty.a
-rw-r--r-- root root 589216 /usr/lib/libopcodes.a
-rw-r--r-- root root 202 /usr/lib/libopcodes.so

$ cat libbfd.so
/* GNU ld script */

/* Ensure this .so library will not be used by a link for a different format
on a multi-architecture system. */
OUTPUT_FORMAT(elf32-i386)

/* The libz dependency is unexpected by legacy build scripts. */
INPUT ( /usr/lib/libbfd.a -liberty -lz )

$ rpm -qp --provides binutils-static-2.20.51.0.7-3.fc14.i686.rpm
binutils-devel = 2.20.51.0.7-3.fc14
binutils-static = 2.20.51.0.7-3.fc14
binutils-static(x86-32) = 2.20.51.0.7-3.fc14
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-04-2010, 05:08 PM
Toshio Kuratomi
 
Default binutils once more

On Fri, Jun 04, 2010 at 10:22:05AM +0200, Michael Schwendt wrote:
> The saga "binutils does not adhere to Static Library Packaging Guidelines"
> continues.
>
> Temporarily the issue had been fixed, then it has been reverted by adding
> "Provides" that violate the guidelines again. When I permitted my checker
> script to reopen the bugzilla ticket, it was quickly closed as NOTABUG
> this time.
>
> binutils : does not adhere to Static Library Packaging Guidelines
> https://bugzilla.redhat.com/show_bug.cgi?id=556040
>
> The ticket that lead to violating the guidelines again:
>
> libbfd.so in binutils-devel needs libbfd.a in binutils-static
> https://bugzilla.redhat.com/show_bug.cgi?id=576300
>
> [...]
>
> I'd appreciate if the Fedora Packaging Committee discussed this and either
> officially excludes the binutils package from the guidelines or adjusts the
> guidelines.
>
> To brief all readers: binutils ships shared *and* static libs, but it
> replaces the *.so files used for linking at build-time with ld scripts
> that only link statically. It has been said that the library interfaces
> are not stable enough to link shared.
>
> $ rpmlsv -p binutils-2.20.51.0.7-3.fc14.i686.rpm | grep /lib
> -rwxr-xr-x root root 881172 /usr/lib/libbfd-2.20.51.0.7-3.fc14.so
> -rwxr-xr-x root root 561296 /usr/lib/libopcodes-2.20.51.0.7-3.fc14.so
>
> $ rpmlsv -p binutils-static-2.20.51.0.7-3.fc14.i686.rpm|grep /lib
> -rw-r--r-- root root 23878 /usr/include/libiberty.h
> -rw-r--r-- root root 1104328 /usr/lib/libbfd.a
> -rw-r--r-- root root 271 /usr/lib/libbfd.so
> -rw-r--r-- root root 274322 /usr/lib/libiberty.a
> -rw-r--r-- root root 589216 /usr/lib/libopcodes.a
> -rw-r--r-- root root 202 /usr/lib/libopcodes.so
>
> $ cat libbfd.so
> /* GNU ld script */
>
> /* Ensure this .so library will not be used by a link for a different format
> on a multi-architecture system. */
> OUTPUT_FORMAT(elf32-i386)
>
> /* The libz dependency is unexpected by legacy build scripts. */
> INPUT ( /usr/lib/libbfd.a -liberty -lz )
>
> $ rpm -qp --provides binutils-static-2.20.51.0.7-3.fc14.i686.rpm
> binutils-devel = 2.20.51.0.7-3.fc14
> binutils-static = 2.20.51.0.7-3.fc14
> binutils-static(x86-32) = 2.20.51.0.7-3.fc14
>
Jakub, if you aren't on this list I can ask questions on the bug report
instead. Let me know.

Here's the things I need to know/confirm to draft a sensible exception into
the policy:

* What's the advantage to shipping shared libraries for binutils if we don't
want people to link against them? (I'm guessing it has something to do
with the number of utilities within the binutils package that can then
link against the shared libraries but I don't know specifically what?)

* Who needs to link against the binutils libraries?
From mschwendt's repoquery run it looks like this::

$ repoquery --disablerepo='*' --enablerepo='rawhide-source' --srpm
--whatrequires binutils-devel --qf '%{name}'|sort|uniq
alleyoop
avarice
CodeAnalyst-gui
eclipse-oprofile
gcl
kdesdk
kernel
ksplice
latrace
libdwarf
lush
mutrace
oprofile
pfmon
sblim-wbemcli
stapitrace
sysprof

* Is there a reason not to treat the shared libraries as internal libraries,
install them to a subdirectory (%{_libdir/binutils/), use rpath in the
binutils utilities themselves, have the other packages link to the static
libraries in %{_libdir}, and not ship a linker script?

* Is there any other technical ideas to consider? Linking the utilities in
binutils statically against their libraries, etc?

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 03:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org