On Wed, Dec 28, 2005 at 10:12:45AM +0100, Moritz Grimm wrote:
> Hi,
>
>
> I'll just go ahead and explain SHARED_LIBS & Co in my own words, the way
> I understand how it works. I hope someone can confirm this
> understanding, or correct me when I got something wrong.
>
> SHARED_LIBS simply enumerates the shared libraries and their version
> numbers. In doing so, it sets a few variables to be used by libtool (or
> other build utilities, that may or may not have to be patched to use
> those variables) and pkg_create in PFRAG.shared. This doesn't actually
> do very much on its own just yet, other than supplying said variables
> that happen to be in a format that libtool likes.
SHARED_LIBS is used to _control_ the versions of all shared libraries
that a port installs. Indeed it sets variables like LIBfoo_VERSION that
you can pass where needed. The important thing is you fix the build so
that you control the version numbers through SHARED_LIBS.
> MODGNU_SHARED_LIBS then takes control over library versioning in case of
> autotool+libtool (if they are using a "good" libtool, e.g. ours when
> USE_LIBTOOL is set to `Yes'). It also lists the to-be-controlled
> libraries and passes an optional argument to each of them.
>
> This argument is either nothing ('') or '-no-undefined'. I do not fully
> understand this one, yet, but setting it properly seems to be related to
> libtool being able to create shared libraries when external symbols are
> involved. The way I understand it, it should be set to '' if `objdump
> -p` shows any NEEDED lines, and '-no-undefined' when not ... that is, if
> there are inter-library dependencies or not. I'm just guessing, but that
> seems to be the difference between, for example, textproc/libxslt and
> audio/libvorbis.
There can be as many arguments as you like between the quotes.
Just look into the software's makefiles, to check the options it is using
in lib*_la_LDFLAGS. If there are variables in there, I prefer to patch the
makefile instead of passing the options (see below).
> In case a port uses different library names than library filenames,
> various _ALIAS variables can be used to make the connection between
> them. I personally didn't get to play with a port that needs this, yet
> -- I hope to see this break eventually to more specifically understand
> it (though I suppose I'm relatively close already.)
No, LIB*_ALIAS is used if the library name does not match the
lib*_la_LDFLAGS variable name. for instance, you can have
SHARED_LIBS= foo-bar 2.3
LIBfoo-bar_ALIAS= foo_bar
which will then define libfoo_bar_la_LDFLAGS instead of
libfoo-bar_la_LDFLAGS.
another case where you can use this: let's say you see
libfoo_la_LDFLAGS= -version-info 4:0:0 $(opt1) $(opt2) $(whatever)
then patch it like
libfoo_la_LDFLAGS= $(librealfoo_la_LDFLAGS) $(opt1) $(opt2) $(whatever)
and add LIBfoo_ALIAS=realfoo in the port's Makefile.
> Last but not least (and as usual), this should preferrably be done with
> USE_LIBTOOL=Yes.
>
> I also see some commit log messages that fix SHARED_LIBS-related
> mistakes. It would be nice if those could be explained a bit. I believe
> it might be very helpful to understand the common pitfalls that people
> already ran into so that they can be avoided more easily by the common
> porting folk. :-)
You should always test changing the version numbers in SHARED_LIBS.
make update-plist will complain if they do not match the versions that
the port is actually installing.
steven
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
