-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings to the Fpc-Devel list:

I recently moved from Linux to FreeBSD as my primary work environment. My development system of choice is FreePascal. I installed FPC-2.0.2 from the official FreePascal distribution tar ball, and all compiled/installed without a hitch; all my CVS sources compile and run.

My next step was to install Lazaruz, and here is where I have run into troubles.

A tar-ball (lazarus-0.9.16-0.tar.gz) install of Lazarus ran well until Lazarus was being Linked. The errors were all linklib related:

the following libraries were not found by ld: glib12, gdk12, and gtk12.

a grep -r in the FPC-2.0.2 source tree revealed the problems, in every case of:

packages/extra/ glib, gtk, and gdk the linklib statements were wrong thus:

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

So, I created a patch to fix the above constructs to read:

  {$ifdef FreeBSD}
     gtkdll='gtk-12';
     {$linklib gtk-12}

For all three libraries; since freebsd names these libraries with a "-" Was this the correct thing to do???

I recompiled and reinstalled FPC-2.0.2 with the above patches applied, re-tested the compiler; all OK!

I went back to the Lazarus source tree gmake clean; gmake and received the following error:

  Free Pascal Compiler version 2.0.2 [2006/07/14] for i386
  Copyright (c) 1993-2005 by Florian Klaempfl
  Target OS: FreeBSD/ELF for i386
  Compiling lazarus.pp
  Linking ../lazarus
  /usr/bin/ld: cannot find -lgdk_pixbuf
  lazarus.pp(113,1) Error: Error while linking

a locate gdk_pixbuf finds: /usr/X11R6/lib/libgdk_pixbuf-2.0

So, at this pount I just sym-linked my libgdk_pixbuf-2.0 to libgdk_pixbuf: ln -s libgdk_pixbuf-2.0.a libgdk_pixbuf.a

and ran gmake again, only to produce:

Linking ../lazarus
/usr/home/bob/lazarus/lcl/units/i386-freebsd/gtk/gtkint.o(.text+0x6f65): In function `DATASOURCEINITIALIZE':
gtkobject.inc:2309: undefined reference to `gdk_pixbuf_get_from_drawable'

Many many more "undefined reference" to something missing in gdk_pixbuf.

so: freebsd's stock-installed gdk_pixbuf does not contain the functions needed! So, I went to ports and found "ruby18-gdk_pixbuf2-0.14.1" a make install provided "gdk_pixbuf2.so" but no "gdk_pixbuf2.a" !!

Funny! I moved away from Linux mainly because of Library-Hell issues :-)

Any thoughts on this would be greatly appreciated. I seem to have run out of things to try here. Surely someone has successfully installed Lazarus on FreeBSD. The Lazarus website says Lazarus will run on FreeBSD, my question is how to make it so?

TIA
Bob

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEup0KAexE5bK/mHkRAmqsAJ9ib0IgapRKv+8Chnr5lODqx/uLBwCeKrMC zjaYKOZcyRn/wgyahTKl/3Q=
=Pzz8
-----END PGP SIGNATURE-----

Hi Bob and welcome to the world of crap.

Seriously and honestly, the FreeBSD porters made a big bad pile of crap when they some years ago decided to name "gtk-12" and others as "gtk12".

Then they added to this pile of crap by renaming it back sometime after 6.0 release.

Long story short, it's not our fault.

Btw. fpc 2.0.2 is in ports now.

You need to symlink those libraries or patch manualy, but we can't change it to the new ones since anyone with FreeBSD 6.0 or older (if they didn't portupgrade) won't work then.

FPC 2.0.4 will have a new mechanism of "libalias" which will enable us to fix this by just adding either command line params (eg: fpc -Laglib=glib-12.so) or changing it in fpc.cfg for all compilations (preffered and porters can do this)

Welcome to the world of shit.. eh sorry I ment unix.

It was written in C what would you expect?

Ales

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ale? Katona wrote

Btw. fpc 2.0.2 is in ports now.

Just a binary distribution right? I did not see the sources in ports, which would have to be patched to fix the lib naming errors.

You need to symlink those libraries or patch manualy, but we can't change it to the new ones since anyone with FreeBSD 6.0 or older (if they didn't portupgrade) won't work then.

I patched
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/glib/glib.pp
in the 2.0.2 source tree to reflect the proper lib names

I then port-installed graphics/gdk-pixbuf, which provided the last missing lib (/usr/X11R6/lib/libgdk_pixbuf.a)

Then Lazarus compiled and linked without error, and seems to run fine.

Are you saying that code produced by this Lazarus/FPC setup will not run properly on older freebsd systems?

Seems to me that FPC-2.0.2 is broken as far as freebsd is concerned. It can't be just lazarus which needs those libs properly defined; so what we have here is essentially a bug fix to FPC itself.

I don't understand, why not just fix the missing "-" in the IFDEF FreeBSD statement, and produce a working FPC?

Bob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuygWAexE5bK/mHkRAmoXAJwIpLvEqBxi6NCSXZtlmFG99iC1wgCfVuGw SR+WySQahOIX+0GtDmwQ+Js=
=bNo7
-----END PGP SIGNATURE-----

Just a binary distribution right? I did not see the sources in ports, which would have to be patched to fix the lib naming errors.

Yes but one guy said he's working on source based one.

Are you saying that code produced by this Lazarus/FPC setup will not run properly on older freebsd systems?

Yes

Seems to me that FPC-2.0.2 is broken as far as freebsd is concerned. It can't be just lazarus which needs those libs properly defined; so what we have here is essentially a bug fix to FPC itself.

Seems to me that FreeBSD is broken as far as everything which uses those libnames... it's not only fpc problem. Old binaries won't work on new freeBSD and vice versa. It's their idiocy not our, we didn't rename those libs 2x.

You don't have a bugfix, you can't ifdef ports version. It doesn't depend on OS version of FreeBSD but on the fact that the person has new ports or not. If someone on 6.0 updates his ports he'll have the new "-" version of glib and others. Same for 5.4.

I don't understand, why not just fix the missing "-" in the IFDEF FreeBSD statement, and produce a working FPC?

See above.

Bob

Your signature is broken.

Greetings to the Fpc-Devel list: the following libraries were not found by ld: glib12, gdk12, and gtk12.

This is a know issue without good solution, since the problem originates in the FreeBSD ports management.

The best solution is:

- for 2.0.2 manually create relevant symlinks to the libs.
- for 2.0.4, use linkaliasing

Funny! I moved away from Linux mainly because of Library-Hell issues :-)

Me too. I really hate the mentality behind this change. It made me reconsider my stance on ports tree usage of FPC. (read: give it up)

(from a mail to sb else explaining this, I'll be adding this to the wiki today in a modded form):

What happens is that all xxx12 libs were renamed to xxx-12 (note that this is STILL different from conventional xxx-1.2)

FreeBSD Ports put this change silently in a doc in nov 2005, and removed the old names in feb 2006 in -STABLE, and refuses to fix the port with a symlink and thus have a longer grace period.

The only way you can know, inside the port building, is to test what name of gtk lib exists (libgtk12 or libgtk-1.2, same for gdk12 and glib12). THE CHANGE DOESN'T FOLLOW ANYT VERSION LINES IF YOU TRACK -STABLE. They refer to pkgconfig or keep on using the -RELEASE ports branch (which is security only),

Of course I can't take a tool that emits gcc parametes seriously (since some ad hoc parsing will probably break on the first gcc change).

So I consider calling pkgconfig/gtkconfig a way to fragile solution long term, I decided to solve it differently, and have some form of config options for them.

This because FPC wasn't entirely innocent too, in that library names in sourcecode ($LINKLIB xxx) couldn't be changed after compilation, this is now fixed in 2.0.4.

The 2.0.4 sourcecode defaults to the new library naming. If you install FPC on a system with gtk compiled from the pre februari portstree (like a stock 6.0 release), you need to add

-XLAglib-12=glib12
-XLAgdk-12=gdk12
-XLAgtk-12=gtk12

to the 2.0.4 fpc.cfg

It is also the most neutral choice. People that disagree with me can try to hack up something to query pkgconfig and install that into fpc.cfg, without risking breakage of the compiler due to some pkgconfig problem.

Note that the a 2.0.4 FreeBSD rc2 will become available today for testing.

This is not a C based problem, you can do the same thing using FPC, but only few people make libraries with FPC in the first place.

This issue is a typical source-based distribution problem, because when you recompile everything from scratch every day (or, often) anyway, you can change a whole lot more without breaking things than if you need to keep binary packages in sync with each other.

Micha

This has nothing to do with source based vs binary. If e.g. debian renamed libs tomorrow inside a branch, it would have the same effect.

Note that the problems are the same in FreeBSD, source based or not.

It is simply bad release management. Probably they want to keep this 5.x and 6.x compat and feel that the hard way will convert most installations quickly.

Library hell exists on all platforms. Running from it is futile. Maybe the maintainers of one platform/OS distribution do slightly better than the others, but in essence the problem always exists.

Even on Windows, where there is only 1 manufacturer, the problem exists.

Michael.

It is not a purely qualitative thing. You can try to minimize it. All distro's do this to some extend.

Maybe the maintainers of one platform/OS distribution do slightly better than the others, but in essence the problem always exists. Even on Windows, where there is only 1 manufacturer, the problem exists.

Windows native misses any library versioning, which is why it is quite notorious. .NET has quit elaborate library (assembly) versioning, but rumours are that the constant security patches can cause problems too.

It generates ld parameters, not gcc parameters. So you don't have to parse them unless you want to use an internal linker.

Jonas

Marco van de Voort wrote

This has nothing to do with source based vs binary. If e.g. debian renamed libs tomorrow inside a branch, it would have the same effect.

They can't do that without breaking all other packages in the archive using this package. They don't get rebuilt automatically AFAIK, and that's where the difference is IMHO.

Furthermore it's policy to change the name of the package when the ABI changes, but that's also what you said: kind of release management.

Micha

I don't understand this. Afaik there is no you be more elaborate in what you think would go wrong automatically?

Furthermore it's policy to change the name of the package when the ABI changes, but that's also what you said: kind of release management.

Same also. The problem is that this is the exception where they didn't.

I suspect they simply didn't want to wait till after 6.x, and wanted to keep 5.x-6.x congruency. (if 5.x implements this change at all).

There is also the matter of -RELEASE vs -STABLE, a principle that is hard to
explain, since other distro's don't implement it;

see it like this: a series of releases becomes STABLE when the generic advise changed to target that series as stable. x.0 versions are typically never stable (the first 4.x stable was 4.4 the first 5.x was 5.3)

If they changed it only for 6.x, they might consider it minor because it is affects non-upgraded 6.0 only, and before the -STABLE moniker is applied to 6.x.

However the difference is that 6.0 is (due to the large compability of 6.x to 5.x, and its stability) way more widely used for serious work than the avg FreeBSD x.0 release. (people were generally afraid of 5.0-DP, and right so :-))

Thnks, will improve the text for the wiki. Not that it changes much, don't like an external called from the compiler.

There is no other way to properly support linking to external libraries, unless you use something like Mac OS X' frameworks (which does support transparent versioning and multi-version support, including name changes of individual libraries part of a framework even if they represent the same library version if you'd feel inclined to do that).

That doesn't mean Mac OS X doesn't potentially have the same library problems though, since most open source based libraries are not distributed as a framework.

Jonas

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

IMHO crap like *_config are only tricks used by C people used to work around defficiencies in their toolchains. There simply should be no reason why you want such complexity. A library has a name, you link to it by name, basta.

If people start renaming libraries we make us resistant to library name changes. Otherwise the compiler needs to support a_config for library x and b_config for package and the end is loose.

Daniël

There's nothing C-specific about libraries, nor about the *config scripts. At most it would be linker-specific.

There simply should be no reason why you want such complexity. A library has a name, you link to it by name, basta.

A library also exist in at least multiple locations, versions (both ABI-compatible and -incompatible with previous versions) and implementations (e.g. a native Mac OS X GTK and an X-based one).

You can of course give everything a different name (which is what often happens in practice), but that doesn't work all that well as demonstrated by everyone's experience.

The whole point of the *config stuff is exactly to be resistant against that.

Jonas

can

Against name changes of course. Supporting the multiple *config stuff could happen via a linklib-like statement in the unit sources.

Jonas

Bob wrote

Funny! I moved away from Linux mainly because of Library-Hell issues :-)

You've to move away from unix then :) I made similiar experiences when porting FPC to Solaris.

That's not the point. The point is that I consider a solution, that tries to collect this data automatically, worse than the current situation.

IOW I consider this cure to be worse (more likely to break a release systematically and harder to support due to a lack of transparancy to end users) than the problem, specially since now we don't have to recompile FPC anymore for a lib change.

My view of source based distributions (in the general software sense) is that when a package maintainer uploads a new library version (changing the library name correctly according to that distro's packaging rules) then all dependent software is automatically recompiled for the new version (and name), and thus no one notices any breakages. Except 3rd parties like us.

For a binary distribution like debian, if a package maintainer uploads a (binary) package with different containing library name, bug reports will be compiled due to other packages being broken now. This package thus cannot transition to the 'testing' (RC) debian distribution, and the only possible fix is to revert the package name to the old one.

Micha

Marco van de Voort wrote

That's not the point. The point is that I consider a solution, that tries to collect this data automatically, worse than the current situation.

There's no reason why a default fallback to the current system couldn't be supported.

IOW I consider this cure to be worse (more likely to break a release systematically and harder to support due to a lack of transparancy to end users) than the problem,

I cannot see how this is more likely to break a release systematically. And it's only as intransparent as we make it (e.g., apart from the "compiling", "assembling" and "linking", there could just as well be a "Determining needed libraries using gtk-config..." message)

specially since now we don't have to recompile FPC anymore for a lib change.

I do not understand this last part. Are you talking about dynamically loading libraries at run time or so?

Jonas

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

There's nothing C-specific about libraries, nor about the *config scripts. At most it would be linker-specific.

There is, those scripts mainly exist because a C compiler cannot determine the dependencies of a library. I.e. if you like libgtk you must also link libglib.

We don't need this in Pascal, the compiler can perfectly determine the dependencies by checking the used units. So the primary reason for this cruft is void in Pascal.

I don't see how *_config guards you against this:
* In case of a version change it will simply return the new version. The .so symlink does this as well. If the new version is incompatible with the old one, bad luck.
* It doesn't guard you against ABI changes, because that it determined at the compiler level. I.e. there is no way to make cdecl code using a register calling convention by using a linker option.

It helps for locations, but we already have a well adequate solution for that: Putting the location in fpc.cfg.

Daniël

You could support exactly the same in C with some #pragma statements in the header files. This is implementation-specific rather than language specific.

But if the new version has additional (or different) dependencies or library names, everything will remain fine with the script (as e.g. with the FreeBSD problem which started this discussion). It's the same with different implementations which maybe be ABI- and API- compatible, but have different dependencies.

It helps for locations, but we already have a well adequate solution for that: Putting the location in fpc.cfg.

Of course you can require the user to manually specify everything in his config file or on the command line, but it's nicer if this can be avoided.

Jonas

This is not for inbetween releases, since not all software will be automatically recompiled in all cases. And in this case specifically it doesn't source and binary packages can be used
together (and in practice, are), and there are build clusters (pointy hat) that check this.

It only is true for full releases, since that forces all apps to recompile, then we get the heat. But this is also so on Linux, usually we only get the indication that something is wrong when new distro (+version) emerges.

If it doesn't exist. But what if it fails? Or if a user pops up in the maillist with a gtk-config related error? Do you really want to support something that you don't control? _and_ at the same time have to maintain the backup too?

No. Simple the alias stuff. See the original msg from me, last part.

To
- change a libname mentioned in a linklib,
- to conditionally add a lib (include lib a if lib b is used, like the libgcc during 2.0.4 pkging, though maybe that must be static),
- or to change order of libs,

no FPC repository or fpc binary recompile is necessary anymore

Then a lot of users of FreeBSD tracking 6.0 or development, or how you'd call it, should have gotten into trouble as well (since there were no symlinks) ?

What do they check ?

It only is true for full releases, since that forces all apps to recompile, then we get the heat. But this is also so on Linux, usually we only get the indication that something is wrong when new distro (+version) emerges.

Mainly I guess because we do not have manpower to check more often :-). Not that I'm saying we should have to check that often...

Micha

Marco van de Voort wrote

> There's no reason why a default fallback to the current system > couldn't be supported. If it doesn't exist. But what if it fails?

The current solution also fails from time to time. And there would switch to disable this gtk-config calling (just like there are switches to disable assembling and/or linking).

Or if a user pops up in the maillist with a gtk-config related error? Do you really want to support something that you don't control?

Yes, I prefer that unless the existing solution is so bad it fails almost all the time, or if the alternative is at least as versatile/ compatible and has significant advantages. Most of the messages about *config failing is that the script isn't found at all by the configure script, which would be a non-issue for us.

_and_ at the same time have to maintain the backup too?

The "backup" must be maintained anyway for libraries which do not come with such a script.

I see this rather as complementary to supporting the *config scripts: if the *config scripts fail, and if the library names defined in the units are wrong, then you can still work around it with these options.

Jonas

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

In that case, there exists no need for gtk-config at all.

That is exactly what Marco's code solves, in a generic way. Solving it by parsing gtk-config, tclConfig.sh, and so on is a work that never finishes.

It's the same with different implementations which maybe be ABI- and API-compatible, but have different dependencies.

Solve it using Pascal:

{$ifdef platform}
uses library;
{$endif}

.... and the compiler will sort out the rest.

If there was a generic way determining library locations: yes gtk-config can only be used to determine the location of one library: libgtk. It is useless for libtcl, for example.

Still, you can put some autodetections in samplecfg, but the compiler itself is really the wrong location to do so.

Daniël

As I said, you do not have to parse that unless you have an internal linker. And even then you only have to parse linker options for the platforms you support. Also, depending on which gtk you link against on Mac OS X you may need to link umpteen gtk/gdk libraries, or need a "-framework Gtk+-Cocoa" or similar linker switch (which would be hard to support with Marco's approach).

The whole point of the *config scripts it that you do not have to care about such implementation details at all.

As explained above, a single platform may have multiple implementations available. You can of course generate three versions of all gtk units for Mac OS X (or even four by now), but that's not really nice either.

It's not just gtk which uses this, at east sdl also does. And the fact that it doesn't solve world hunger does not mean it's not useful to support it.

Still, you can put some autodetections in samplecfg, but the compiler itself is really the wrong location to do so.

samplecfg only works at install time of the compiler, which is the wrong time. People don't decide at install time which package, which variant and which version of it they will want to use one day.

The compiler or linker is the only right place to do it (unless you wrap the whole thing with a configure script and Makefiles, in which case you can do it there -- but our compiler largely replaces exactly that).

Jonas

Yes. But probably newer apps depend specifically on the upped version as a workaround, and not on "a gtk1" as we do. (or worse, we don't depend on gtk at all) so the amount of other breakage was probably less because of that.

Also this change was at the same time as the importing of libtool (BSD ->libtool GNU libtool), there was a lot of movement already.

building all 13000 packages.

The core infrastructure of everything that is built on top of gcc is brought into a consistent state by the distro creators before it goes out of the door. We will never be able to 100% match this. Specially since the toolchain services are generally very gcc centric, and something else is usually not even tested.

For FPC this is not done, so we have to act after the release.

Not that I'm saying we should have to check that often...

We would have to have people inside the distro's to do that.

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

Ok, with gtk-config the right way to get the libraries is "gtk-config --libs". With tclConfig.sh you have to source that in a shell script and read environment variables afterwards.

So, in order to support this, we would need to write a hack when a {$linklink gtk} occurs and write gtk-config specific code. For a different library we would need a different hack.

Also, fact is we do have an internal linker and it will hopefully be used for most platforms in the future. Ultimately it will go in the same direction as with the assembler readers even for external linkers: In order to fully understand the parameters, the compiler must understand them.

Generate 3 units, and introduce some unit aliases for gtk like Marco did for libraries, problem solved. That is still a lot more generic solution than *-config and a lot less work.

We should design a system that does solve world hunger. I'm serious about that: if we want to be a more professional tool than C, we should not copy the defficiencies. Makefiles are one of them, Autohell is another, and I consider this one such a thing as well.

This we agree on, the compiler should do the work.

Daniël

Of course not. You should never change a {$linklib magicstring} into some command. The exact command(s) to be executed would have to be embedded in the unit with a compiler directive (and probably, just like library name, be ifdef'd per platform).

Also, fact is we do have an internal linker and it will hopefully be used for most platforms in the future.

I do not see this happening any time soon for e.g. Mac OS X.

Ultimately it will go in the same direction as with the assembler readers even for external linkers: In order to fully understand the parameters, the compiler must understand them.

Yes, this is a downside of integrating everything (with the upside being speed and memory usage, obviously).

Of course making the developer type in everything manually is always more generic and less work for us. That is not my point, and I'm not against providing this functionality. As I said in my reply to Marco, I consider it complementary, as a last resort if all else fails.

I think all this "competing with C" and not-invented-here syndrome is downright silly, along with all the claiming that most bad things come from C. If anything, it comes mostly from the standard Unix design philosophy (small, well-delineated tools which perform their core function and *only* that core function). Most *nix C compilers follow that principle very well, but other C development environments are more integrated (like commercial Mac and Windows IDEs, where you sometimes can hardly e.g. tell the compiler from the linker).

We are only a small team, and by playing the elite Pascal geeks who are going to show how much the C world sucks by doing everything different, we are going to
keep getting stuck by having to reimplement everything because we cannot work with what is already there. People often talk about how stupid Mac users supposedly are and how elite they consider themselves. Well, this Pascal-elitism and C-hostility by some gives the Pascal community just as bad a name, even though just like in the Mac community most people probably couldn't care less about these little superiority wars.

To get back on topic: the more hacks you add to work around already- existing infrastructure "because we don't want to rely on external tools", the more you force yourself to keep doing that more and more forever in the future. If you like that, fine. I don't.

The problem in this particular case is not C, it is the way most OS's (do not) support library management. There are various workarounds to make it less painful, and this *-config script thing is one way which is fairly straightforward and which is being adopted in various places (sometimes even fairly general, grouping everything together in a global pkg-config script). Adding support for using this existing infrastructure is good if it can help solving some problems without people needing to know the nitty-gritty details of how the libraries are called on their system.

Above you said that the compiler is the wrong location?

Anyway, I never said I agree with this principle (although it sure is very convenient in a lot of cases, in others it's very annoying because it requires that you roll your own solution for everything). I simply said this is how the compiler works.

Jonas

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

Above you said that the compiler is the wrong location?

The compiler is from a software engineering point of view the wrong location to call gtk-config and clones. However, it is the compiler's task to pass the libraries a unit needs to the linker.

As this is contradictory, my conclusion is that we should not use gtk-config.

Daniël

So you will claim that auto* tools and configure scripts are a good design ?

If anything, it comes mostly from the standard Unix design philosophy (small, well-delineated tools which perform their core function and *only* that core function).

No these are separate things. The C compiler vendors do not provide a common platform resulting in a differing mess that has to be held together with scripts.

These differences do not add expressive power as the unix tools allow when combining them in a smart way.

Micha

Micha Nelissen wrote

No these are separate things. The C compiler vendors do not provide a common platform resulting in a differing mess that has to be held together with scripts.

Of course they don't. Unlike some other languages where such things are standardized quite clearly, (most) consistency, dependency and linking issues are beyond the scope of the official C-standard.

What a luck that at least the code is portable from one platform to another. If you have a spare floppy to transport it. :->

Vinzent.

Vinzent Hoefler wrote

Of course they don't. Unlike some other languages where such things are standardized quite clearly, (most) consistency, dependency and linking issues are beyond the scope of the official C-standard.

I'm not talking about the C language, but the vendors, the C library implementors, etc.

Micha

The setup of the whole linkaliasing is to change the $linklib into mere identifiers (while compiling units) that can then be mapped at will to real libnames when determining how to link, with the default being 1:1. This means we could move the whole ifdef {$linklib mess to a platforms (or distro) specific fpc.cfg #include and more importantly OUT OF SORUCE (regardless of internal or external, though with external more of the discovery process must be done up front).

I want more out of source.

>Also, fact is we do have an internal linker and it will hopefully be >used for most platforms in the future. I do not see this happening any time soon for e.g. Mac OS X.

I didn't see it happening at all half an year ago, but thanks to Peter...

It is inevitable. But that doesn't mean there is only one way to integrate stuff. It must be done cautiously, and pragmatic.

The idea is being able to be able to generally fix an existing release _after_ a change becomes know (read: a distro release). It can be as simple as saying "copy and paste this set", or download this source and run the utility.

That is not my point, and I'm not against providing this functionality. As I said in my reply to Marco, I consider it complementary, as a last resort if all else fails.

I consider pkgconfig very important. But I want to have it feed a store, a FPC configuration file.

This because I want to be able to say "mail me your compiler state", and send back a new one. Too much automatism will make things less transparant. To the user, but also to the one who has to support it.

Supporting multiple versions is hard, and other people designs are not always perfect or tailored to our use. Do I have to mention XCode here? :-)

That was Almindor not me. However there is a point in this that I agree with. All this infrastructure is not designed for anything but the standard toolchain. It is not like e.g. Win32 for any vendor to build on top off.

Also even for them there are bumps, but these are polished away for the default systems in the distro release engineering. E.g. for a new compiler the whole build environemnt is changed and made consistent. But for us stuff breaks.

That is not "not-invented-here" syndrome or C phobia, but a simple reality. I agree a bit with Florian that there is a fundamental problem in the Unix (and then specially the Open Source parts) way of doing here. Something I would never have agreed on say 5 years back.

If anything, it comes mostly from the standard Unix design philosophy (small, well-delineated tools which perform their core function and *only* that core function)

_eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux distribution? Install *BSD, build a world, and see it rolling over your screen :-). Unix nowadays is gigantic, and monolithical. These are old sentiments.

Most *nix C compilers follow that principle very well, but other C development environments are more integrated (like commercial Mac and Windows IDEs, where you sometimes can hardly e.g. tell the compiler from the linker).

IMHO the C _compiler_ way of things is not Unix philosophy, but simply the lack of memory of K&R's their PDP7. Batchwise processing allowed less memory. See the various Unix history books. Of course there was much revisionism afterwards.

we are going to keep getting stuck by having to reimplement everything because we cannot work with what is already there

Nobody said that. And we don't. We linked to C libraries since before I joined FPC. I personally made the libc port, _before_ there was Darwin on the horizon, just because I want to try to have the best possible system. Both from a support as user perspective.

But that doesn't mean we mindlessly must follow a path that wasn't designed for us. We are different, and can never mask that on Unix, until we can interpret C headers and can use auto* seaminglesly. That has burdens, but also advantages.

[[more perceived elitism deleted]

To get back on topic: the more hacks you add to work around already- existing infrastructure "because we don't want to rely on external tools", the more you force yourself to keep doing that more and more forever in the future. If you like that, fine. I don't.

I want to base on a case by case basis, with a bit of caution.

LD yes, hard to avoid, even as backup. gmake: yes, at least until we have something more fitting for us. lipo: don't see a problem.

gtk-config? Seem to do awfully lot, and call scripts from the compiler binary, selecting one by some magic way and parse it and try to merge it with our own state and support that?

I'm sorry, but you accuse us of C phobia, but this all sounds a like a leap of faith that only a slashdot linux newbie would make, not a seasoned decade old OSS developer.

Let's forget about all the advocacy and focus on this particular case. What can we do as a grander plan to tackle the increasing demands on linux backend configurability and ease of use at the same time?

I assume you don't have time atm to hack up an initial -config implementation to see a few distro generations how it is going?

Specially your remarks (in the first quoted paragraph above) about more linker data in source scares the hell out of me from a support perspective.

I know, but I was trying to point out that e.g. on Mac OS X sometimes you may need

-lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf

and sometimes

-framework Gtk+-Cocoa

and sometimes

-framework Gtk-Carbon

(and there's a fourth "native" Mac OS X gtk port underway, because the two previous ones were never really finished)

You need something more than merely the remapping of library names.

I don't really care where exactly the information is stored (although the unit somehow seems logical to me, if you want to keep the interface and libs specification together), but if we change things from the way they are now, then the information should be dynamic (i.e., not merely determined at install time, because that only shifts the problem) and preferably come from available automatic sources (as opposed to the developer having to specify it).

The GNU tool chain is at the same time more and less static than the Mac OS X tool chain. Apple changes internal stuff concerning libraries and the like all the time for their new whizzbang features (zero-link, fix-and-continue, prebinding and then not anymore, ...). It would be hell to keep up with that.

The problem is that it needs to be "refed" every time you compile something using particular units (those depending on libraries requiring this mumbo-jumbo). Not to mention on multi-arch systems (like darwin/i386 which can also run darwin/ppc binaries) where the parameters will depend on the architecture you are compiling for (unless you have perfectly symmetrical needs for ppc and i386 with just a different directory name somewhere, but that's often not the case because ppc is most of the time supported back to Mac OS X 10.2.8, while i386 support only ).

That's what "-al -s" is for.

Supporting multiple versions is hard, and other people designs are not always perfect or tailored to our use. Do I have to mention XCode here? :-)

I do not think a closed source IDE which is being (re)built from scratch and being stuffed with new features all the time (as opposed to first fleshing out the basics) to give Steve Jobs something flashy to talk about at the next WWDC is comparable to a script which generates some linker parameters. And a bunch of linker parameters is exactly tailored to what we need.

I was replying to a mail from Daniel.

That's more or less what I'm saying below, which you are refuting.

Many small things (and some larger, like OpenOffice.org) together make for large sizes.

gtk-config? Seem to do awfully lot,

It prints a string with linker parameters.

and call scripts from the compiler binary, selecting one by some magic way

In the same magic way as we select the external assembler and linker.

and parse it and try to merge it with our own state and support that?

For the external linker not a single bit of internal state merging is necessary. It's just a fire-and-forget string. For the internal linker, yes, you need some kind of parsing just like you need it for the assembler reader and the binary writer (like Daniel mentioned iirc).

I'm sorry, but you accuse us of C phobia, but this all sounds a like a leap of faith that only a slashdot linux newbie would make, not a seasoned decade old OSS developer.

I think you are overstating the problem of using the output of gtk- config.

Jonas

Op Tue, 18 Jul 2006, schreef Jonas Maebe:

You need something more than merely the remapping of library names.

As I said, you can remap unit names. At some point the user will have to decide to which one he wants to link, doing it by a unit name remap looks an elegant solution to me.

Doesn't matter: Marco was pointing out that all the (bandaid) stuff was designed for a single toolchain: gcc. We have the opportunity to do better, and therefore save our users from all kinds of bandaids gcc users need.

If you think supporting gtk-config doesn't hurt the users: If we don't fix this properly, our users will feel necessary to write this kind of band-aids for their own libraries as well.

I'm quite sure it will at some point be necessary to parse it even for the external linker, we had our own parsers before we had an internal assembler.

Daniël

And I was talking about the deficiency of its language definition that leads to exactly what your complaining about.

Don't make the mistake to reduce language to syntax only.

Vinzent.

I know. We already need more to change libs from static to shared. And I knew there was more, which I wanted this as formally undocumented functionality. IIRC I referenced that in the mail to core about the linkordering.

I'm not entirely happy having put this in parameter form. A keyword based configuration file is a better way.

Yes and no. The unit should only reference some abstract keyword, and the mapping to exact actions should happen outside the source. Otherwise overriding becomes nearly impossible.

Maybe this can be easily introduced by having a second parameter to linklib. something like

{$linklib packagename,libraryname} // the comma makes it possible to
keep the old syntax also for migrational purposes.

We can then e.g. easily transform either on libraries or on groups of libraries ( the packagename above, in the linklib), e.g. to -framework.

This would work for your system too, for the same reasons. If something fails (e.g. wrong script called, since the new version names it differently, or some distribution renames it to something-x.y because of a newer version occupies the "something" name), you'd be able to override simply by installing a new config file (no new binaries or precompiled sourcetree needed)

This is also the main reason to make this config a separate file, or a fpc.cfg #include. Default not for user editing.

So the hoisting out of the source (and too much hardcoding in t_*) should be separate from if we go -config or manual. The abstract, transformable representation is needed in either case, also to allow overrides on the -config usage.

but if we change things from the way they are now, then the information should be dynamic (i.e., not merely determined at install time, because that only shifts the problem) and preferably come from available automatic sources (as opposed to the developer having to specify it).

You could simply exit with a hint to run the configuration tool if you detect that ldconfig has been run. ldconfig is the key here, because to my limited knowledge it should be run after library changes.

But IMHO this automatic behaviour is a disaster waiting to happen. Untransparant, unsupportable, to easily broken, hard to override (it is easier to let the user make FPC specific config changes, than to have him edit global pkgconfig and risk breaking his KDE)

But as long as the automated is not the default (which then can be automatically turned on by IDEs), I don't care, as long as I don't have to support it.

(Most of the rest of the discussion skipped, only replying to concrete parts. Viewpoints won't change with more discussion anyway)

The problem is that it needs to be "refed" every time you compile something using particular units (those depending on libraries requiring this mumbo-jumbo).

(I didn't get this? Surely reading an own config file is quicker than calling a bunch of external _scripts_ ?)

Too crude. Only the output, not the input. Maybe combined with -va it could work if enough msgs were emitted with relevant info, but way overkill for 99% of the cases that revolve recognizing variations of a few common scenario's.

(Unix philosophy)

I haven't seen small things made in recent years, and previously small things have grown big.

gcc isn't exactly small, neither is glibc or KDE or Gnome or Eclipse or Mozilla or Evolution or Samba, or X or anything that the user sees. And nearly any of them are not run by volunteers anymore either. Nearly all have fulltimers.

The only stuff that is small are the remnants of the said eighties unix culture. Tail,wc and friends. The newer branches of that family (perl, python etc) are all again huge.

More fire-and-hope. And you need to parse, otherwise you can't override except by turning the whole system off and doing everything by hand.

Alright everyone, just stop this ok?

I was angry like hell when I first read the ORIGINAL poster's message about FreeBSD (hint, topic no longer valid in your discussion) I got even more angry and my response was very immature. I would like to apologise to everyone and especialy the original poster for my tone.

This whole discussion is useless. I hate to be the one who brakes the party, but it all started because I said a few completly untrue things about C with relation to binary compatibility. Honestly I didn't expect you guys to catch up (when I cooled down that is).

So there it goes, return to whatever you were doing before and we'll all be better of I think.

Ales

Aleš Katona wrote

This whole discussion is useless.

Better library linking support is not useless.

Jonas