LinkLib Issues In freebsd Lazarus

[Mike Meyer]

In <44BBFE49.4080602 at tania.servebbs.org>, Bob <bob at tania.servebbs.org> typed:
> I have been involved in a parallel discussion on the fpc-devel list, and
> have discovered a few facts which will impact the manufacture of a
> freepascal Lazarus port. In fact, what I have learned will impact the
> usability of FPC on freepascal itself.
> 
> The "problem" which initiated this thread was the "wrong naming" of some
> libraries. Well, it turns out that this renaming was done mid-stream by
> the freebsd development team, and not by the freepascal folks.
> 
> It seems that from freebsd 6.0 to freebsd 6.1 (the one I am using)
> library names were arbitrarily changed. The ones I ran into were libgdk,
> libgtk, and libglib. In all previous versions (prior to 6.1) of freebsd,
> the lib versions 1.2 were named libgdk12, libgtk12, and libglib12 they
> were changed in 6.1 to libgdk-12, libgtk-12, and libglib-12
> respectively. I wonder how many more library names were changed? This is
> a real blow to any third party software developer, who's software will
> likely start to bomb on freebsd6.1, where it ran just fine on 6.0

I can't help with this. I have no idea why it was done - it certainly
wasn't discussed on -hackers.

> BIG problem! If I compile a program on my 6.1 system, which makes any
> dynamic calls to these libraries (and possibly others as yet unknown),
> that executable will ONLY run on freebsd 6.1, and bomb on all prior
> versions. My "fix" of patching the freepascal 2.0.2, or your method of
> sym-linking, while fixing the local problem of compiling Lazarus, breaks
> all portability to previous freebsd installs. This is a bad thing the
> freebsd folks have done!

Well, one solution is to distribute sources - which works especially
well if you provide a port. See below for more on that.

If you want to distribute binaries, you could simply include the
correct libraries in your tarball, and only install them if they
aren't installed.

> There are some dirty work-arounds, and according to the fpc developers,
> they will be implementing some new tools to deal with this in fpc-2.0.4,
> who's rc2 has just been released.
> 
> I can see making these kinds of changes from a 5.x version to a 6.x
> version, as bad as even that would be, but to make such a change from
> within the 6.x branch is pretty inconsiderate IMHO.
> 
> Given the above, it would be senseless to create a "port" of lazarus,
> which would require a "port" of the "patched" fpc sources, (as a
> dependency), and then have a development system which was tied to a
> particular version of freebsd.

No, it's not senseless. You can *ask* the various libraries what they
need, by runnig "gdk-pixbuf-config --libs", for example. However, you
shouldn't need to do that. Adding something like "USE_GNOME=gdkpixbuf"
to your port Makefile will cause the Makefile to add all the
appropriate dependencies to CFLAGS.

Except you may not use CFLAGS, and may have to go back to
gdk-pixbuf-config to get the data you need. You may even need to tweak
the output to make it accpetable to fpc.

Basically, this change is only really painfull if you want to
distribute binaries. In that case, you could, as mentioned
above,distribute binaries of the libraries as well.  Or you could not
support anything prior to 6.1 (actually, that's not correct - my 5.5
system has the new library naming).  Or - since this change is in the
ports system, not FreeBSD proper, and the ports tree can be updated
independently of the base system, require that 6.0 users update their
ports tree and the libraries in question.

Please note, I'm not trying to defend or justify this change - you
pointing it out is the first I'd heard of it. I'm just trying to point
out some ways you can deal with it.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.