Problem with .so numbering on FreeBSD in contrast to Linux

[Thomas Schmitt]

Hi,

Jeremy Messenger wrote:
> The API can be check version inside the *.pc file by via configure.

Yes. But that protects against mishaps at
install time, not against mishaps at run
time.
What if the asserted preconditions get
changed afterwards ?


> Or/and use the header (*.h) to check API stuff.

With our libraries, there is the application's
idea of the feature set, the compile time feature
set and the run time feature set.
Implemented as application defined minimum
version numbers, library defined header macros,
and a library run time function.

So at any stage of compilation and linking
our code can compare version numbers and defend
itself against mismatch. Help from outside tools
is appreciated but not essential.

If it wasn't so suspicious that libtool
behaves so cumbersome on FreeBSD, i would
shrug and just go on.

Now i still hope for somebody to show up
with a pointer to the decisive FreeBSD specs.

If not, then i'll go for constant libburn.so.4.


> But you don't really need to
> do that and you can tell your port mainainer [...]

Porting libburn is not trivial because of
the generic SCSI command transport. So if
we have a FreeBSD system adapter module anyway
then we can as well take care of FreeBSD
compliant .so numbering.

I am thankful to J.R. Oldroyd for producing
the ports. Nevertheless it cannot harm if the
source tarballs work out of the box too.
autotools has the potential for that.


> As for the libtool2 that still doesn't has fix.
> Yes, I guess, someone will have to report to libtool2.

I am not so sure that it will be accepted
as bug. Meanwhile it looks intentional to me.
Strong runtime mismatch protection, or so.

That shall not keep me from having a libtool
template on my machine, which suits better my
projects' needs.
I just have to define those needs.


Have a nice day :)

Thomas