Date: Mon, 26 Feb 1996 14:26:32 -0800 (PST) From: asami@cs.berkeley.edu (Satoshi Asami) To: thorpej@nas.nasa.gov Cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/gnu/usr.bin/ld/ldconfig ldconfig.c Message-ID: <199602262226.OAA13291@silvia.HIP.Berkeley.EDU> In-Reply-To: <199602262140.NAA05885@lestat.nas.nasa.gov> (message from Jason Thorpe on Mon, 26 Feb 1996 13:40:31 -0800)
next in thread | previous in thread | raw e-mail | index | archive | help
* One could argue that you could add Yet Another Option Flag to ld(1)
* separate from -l to specify the major number of the lib. Looking at
* NetBSD's ld(1) manual page, it looks like -m is free, and somewhat
* intuitive.
The problem is that "minor" also starts with "m".... :>
* Alternatively, you could take it a step further and use -V
* (not -v, in case someone thinks that means "make the linker verbose" :-)
* to trigger "library version".
"-V" is already taken in FreeBSD (and according to the man page, it's
taken in NetBSD too).
-V version
Put the given version number into the output shared library (if
one is created). Useful to make shared libaries compatible with
other operating systems. Eg. SunOS 4.x libraries use version num-
ber 3. Defaults to 8.
Although I'm not exactly sure why we need this, I've only seen "-o
libfoo.so.1.2" type of command lines, so maybe we can take it out.
* I.e. some programs might want a featureset
* found in a specific _minor_. The command like could be parsed such that
* a -V affected the next -l, so you could do:
*
* ld -o foo foo.o -V 12.2 -lc -V 0.1 -lutil
By the way, there should no need for specifying a minor version
number, as the major version number would be bumped if there is a
change that is backwards-incompatible. (At least that's the rule in
FreeBSD -- added functions/bug fixes mean bump minor, deleted
functions/changed functionality mean bump major.)
Yes, we can still do it this way, I think it would have been much
easier and intuitive if we could just append it to -l than adding a
new (stateful) flag.
* However, this begs the question of why ports (I'm assuming you mean 3rd
* party software) that you compile from source "require different versions
* of shared libraries". That seems ... rather broken.
No, it's perfectly natural. There are tons and tons of software
written for tcl-7.3/tk-3.6, and many of them would break if you link
them with the newer versions. :)
However, if you are talking about system (i.e., non-"ports") shared
libraries, I agree, the porter should make the port use only the
latest system library.
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602262226.OAA13291>