packaging shared libraries without autoconf and automake
I'm building a package for levmar. Upstream does not use autoconf,
automake, or libtool. The supplied makefile builds a statically linked
library, liblevmar.a. With trivial changes I can build a shared library
liblevmar.so instead, and I've verified that this works with the
supplied demo program.
I don't want to replace the upstream Makefile with use of autoconf and
automake, and the libtool documentation doesn't really explain how to
use libtool without those. Can I just do the shared library versioning
"by hand", by creating the appropriate symlinks in the package? Or is
there some other preferred way to deal with this kind of situation?
Thanks!
Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
01-23-2010, 01:19 AM
Ulrich Drepper
packaging shared libraries without autoconf and automake
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/22/2010 05:22 PM, Eric Smith wrote:
> Can I just do the shared library versioning
> "by hand", by creating the appropriate symlinks in the package? Or is
> there some other preferred way to deal with this kind of situation?
The link line has to defune an SONAME for the DSO.
Take a look at the elfutils makefiles. Yes, it's using autoconf but it
doesn't matter. The rules can be copied anyway.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
packaging shared libraries without autoconf and automake
Once upon a time, Eric Smith <eric@brouhaha.com> said:
> I don't want to replace the upstream Makefile with use of autoconf and
> automake, and the libtool documentation doesn't really explain how to
> use libtool without those. Can I just do the shared library versioning
> "by hand", by creating the appropriate symlinks in the package? Or is
> there some other preferred way to deal with this kind of situation?
If upstream isn't building a shared library, then you have no good way
to set a version and then maintain an ABI. If other software that links
against the library is only expecting a static, they won't expect to
have to deal with ABI changes either.
No matter how you make a shared library, I'd suggest getting that change
accepted upstream before trying to put it in Fedora.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
01-23-2010, 03:14 PM
Ulrich Drepper
packaging shared libraries without autoconf and automake
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/22/2010 08:37 PM, Chris Adams wrote:
> If upstream isn't building a shared library, then you have no good way
> to set a version and then maintain an ABI.
Not true at all. Why should this be the case? The package maintainer
should ideally _always_ be the one deciding the versioning. I actually
hope this would be done more frequently.
Of course this requires intimate knowledge of the ABI. But if this is
available the results can be much better.
The reason is that upstream maintainers often don't take advantage of
the technologies gcc and the Linux runtime provide. We can, in many
cases, prevent an ABI breakage and/or bumping of the DSO version with
techniques like symbol redirection, symbol versioning etc. That's often
just not available elsewhere. The result would be that DSOs use
internal versioning and updates don't break existing code by replacing
DSOs with versions with different names.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
packaging shared libraries without autoconf and automake
Once upon a time, Ulrich Drepper <drepper@redhat.com> said:
> On 01/22/2010 08:37 PM, Chris Adams wrote:
> > If upstream isn't building a shared library, then you have no good way
> > to set a version and then maintain an ABI.
>
> Not true at all. Why should this be the case? The package maintainer
> should ideally _always_ be the one deciding the versioning. I actually
> hope this would be done more frequently.
The Fedora policy is to push changes upstream, not develop differences
from upstream in the Fedora package. Putting shared library versioning
in the exclusive hands of the Fedora packagers means we'll be back to
the early days of shared libraries, where one distro used libfoo-1.1,
one used libfoo-2.0, and another used libfoo2-1.0. That was annoying
and confusing, and let to years of people insisting on statically
linking everything.
Fedora isn't the only Linux. Managing the shared library versioning in
Fedora packages means that other distributions can't easily take
advantage of it and stay in sync.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
01-23-2010, 04:48 PM
Eric Smith
packaging shared libraries without autoconf and automake
Ulrich Drepper wrote:
> Take a look at the elfutils makefiles. Yes, it's using autoconf but it
> doesn't matter. The rules can be copied anyway.
Thanks, that was exactly the sort of thing I was looking for!
Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
01-23-2010, 04:51 PM
Eric Smith
packaging shared libraries without autoconf and automake
Chris Adams wrote:
> If upstream isn't building a shared library, then you have no good way
> to set a version and then maintain an ABI.
[...]
> No matter how you make a shared library, I'd suggest getting that change
> accepted upstream before trying to put it in Fedora.
I dug into it a bit more, and tt turns out that upstream does provide a
way to build a shared library. They use a separate Makefile for that.
I've submitted the package (levmar) for review. Since it will be my
first Fedora package, I'm looking for a sponsor.
Thanks!
Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
packaging shared libraries without autoconf and automake
