I heard that the gtk1 libs under FreeBSD are libglib-12.so, libgdk-12.so and libgtk-12.so.
But at the moment the linklib directive for FreeBSD defines

    {$ifdef FreeBSD}
      gtkdll='gtk12';
      {$linklib gtk12}

without the '-'.

Can someone with FreeBSD please test if changing

packages/extra/gtk/gtk/gtk.pp
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/glib/glib.pp

fixes the issue.

Mattias

To my best knowledge, this naming depends on what version and what packages branch one is using .

FreeBSD, when confronted with this says to use pkgconfig, and doesn't want to help out with a couple of symlinks to ease the situation. IOW they don't care about anything but GCC. I recommend filing a send-pr about this.

Since there is no way currently to make lazy bound dll names variable without recompiling on target, and most people are using release versions, I chose to wait with this change till more people are over to the -1.2 syntax, to keep the amount of users that have to symlink manually to a minimum.

This symlink/library practice on linux/unix is simply a mess, and I personally also don't see another portable way but to use tools such as pkgconfig and friends. Afaik the output of pkgconfig is not gcc specific, but ld-specific (at least the output of "sdl-config -- libs") is. So if you want to use it for an internal linker, you indeed have to parse that output (as opposed to similar statements in the source).

Jonas

Two or three months ago I tested Lazarus on FreeBSD 6.0 RELEASE. After installing some missing libs (like pixbuf-devel, etc.) it compiled and run without any problems. Lazarus version was 0.9.12 IIRC.

I'm afraid that that will open a whole can of other slight incompabilities, path problems etc. Moreover it doesn't help us to tackle problems _after_ deployment.

But the main difference with GCC is that gcc can link precompiled stuff (e.g. -devel libs), and only decides about lib names on the point of linking. We have library names hardcoded in the .ppu's.

A simple solution would be to regard the linklib statement as an alias, that can be replaced with a different name somewhere else. In that case, a distribution maintainer can relatively simple add some config options to e.g. alias gtk to gtk12 or libdl to libc etc.

Even if we get pkgconfig working, if something is wrong, pkgconfig gets a new version etc etc, we can only say "wait till the next version", or must create emergency fixes for releases already in the wild. (FPC version 2.0.4sp1 ? :-)

I don't say that pkgconfig shouldn't be done, but I think the main problem that must be fixed is the hardcoding of library names in the .ppu

forwarded:

I am not fit in Linux and I have only one SuSE-10-Installation running where I had also some trouble when installing Lazarus. But on several PCs I have 5 FreeBSD installtaions running from FreeBSD 5.5RC, 6.0 Release, to 6.1RC in several Patchlevels. I installed Lazarus from source on 4 of them using version 0.9.12, 0.9.14 and 0.9.15 (from SVN).

All these FreeBSD installations show the same behavior and set the minus char into the library name. So for me, this seems to be FreeBSD specific. But I could live with this problem (if documented) when installing a Lazarus beta version in FreeBSD from source. gmake's Makefile additionally could test the 3 libs and set (if missing) those symlinks or can patch the Free Pascal source files if needed.

But this behavior is of course not acceptable for a final 1.0 binary installation. Here those libs _must_ be linked and later unlinked by a deinstaller (even this symlinking is not so nice). But a severe problem seems for me, that the produced and distributed apps which are linked against glib, gdk und gtk will have the same problem and may not run if the wrong filename is used on different FreeBSD target.

But on the other hand I am a little bit confused about the answer and that "pixbuf-devel" had to be installed? There are no *-devel packages in (Free/Net/Open)-BSD. These are typical Linux names. Did he really compile a native FreeBSD version or did he install the Linux version in the Linuxulator? The Linux version of course uses the RedHat-libs in /usr/compat/linux/... without the "-". All BSDs install always complete libraries. a glib, gtk oder gdk-pixbuf includes the libs themselves and all headers etc. There are no additional developer libraries available! (I never tried to use such a combination for Lazarus except on NetBSD. There Lazarus/Linux is working but Free Pascal/Linux traps :-( so Lazarus is unusable in any combination at the moment.)

I use different versions of the FreeBSD ports for the different installations, mostly actual ones installed via ctm. The behavior is the same when the ports are installed with the release.)

I hope, that these informations will help a bit to fix the problem.

-----------

Mattias

But on several PCs I have 5 FreeBSD installtaions running from FreeBSD 5.5RC, 6.0 Release, to 6.1RC in several Patchlevels.

All fairly new versions, except for 6.0. But you probably use -HEAD there for the ports tree? The branch from the ports tree that you use is where the difference is afaik. I'm a bit surprised that 5.5RC goes this way. This breaks compat with earlier 5.x releases afaik.

I also have seen installation that have libgtk-12.so btw. So the problem is even more complicated

I don't think this is FPC's task.

First there should have been a longer grace period from the GTK port, but that is beyond our control.

Second, I don't want to hardcode this kind of OS detection into the makefiles, that is waiting for trouble, and we are always reacting in retrospect.

Fixing/keeping this kind of stuff is for the distribution packager, to be done in a way specific for a certain distro (be it a linux distro, FreeBSD or fink)+version. That is in practice how
it works for other packages.

However IMHO what FPC should add is a possibility to switch between both notations without a full recompile or sed like source editing. We can workaround this with a IFDEF, but the next time it is trouble again.

The ports maintainer must then detect what is actually available, and then adjust e.g. fpc.cfg appopriately.

seems for me, that the produced and distributed apps which are linked against glib, gdk und gtk will have the same problem and may not run if the wrong filename is used on different FreeBSD target.

There is no help for that.

But on the other hand I am a little bit confused about the answer and that "pixbuf-devel" had to be installed? There are no *-devel packages in (Free/Net/Open)-BSD.

I know. I wanted to illustrate that the problem that lib names are hardcoded is not only for FreeBSD. If e.g. some distro renames some lib differently on Linux, you have the same problem.

I use different versions of the FreeBSD ports for the different installations, mostly actual ones installed via ctm.

What is ctm? Or do you mean cvsup?

A but old I know but I think we should remake the "glib and friends" unit to lazy linkers. Anyone using them uses libc anyhow (which = ld in fBSD) so once they use lazy linking, a simple "try the old name, then the new name" in initialization section would fix this and other future freeBSD-porters fuckups.

I tried converting them, I even talked Loesje into giving me his tool but I didn't find the time for it yet. If anyone has anything which can simply do this, or has the time to do it manualy it'd be great.

Ales

P.S: I'm ofcourse willing to test it once it's done/ and or help with the init part.