Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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. 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. That was Almindor not me. I was replying to a mail from Daniel. 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. 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 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:33, Micha Nelissen wrote: 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Tue, Jul 18, 2006 at 01:22:40AM +0200, Jonas Maebe wrote:
libnames when determining how to link, with the default being 1:1.
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 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.
discovery process must be done up front).
I want more out of source.
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),
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_ ?)
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.
That's what -al -s is for.
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)
_eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux
distribution?
Many small things (and some larger, like OpenOffice.org) together
make for large sizes.
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.
and parse it and try to merge it
with our own state and support that?
For the external linker not a single
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 18 Jul 2006, at 12:05, Aleš Katona wrote: This whole discussion is useless. Better library linking support is not useless. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
-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. 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) 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- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Aleš Katona wrote: 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. Welcome to the world of shit.. eh sorry I ment unix. It was written in C what would you expect? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Ale? Katona wrote: 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. Welcome to the world of shit.. eh sorry I ment unix. It was written in C what would you expect? 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, 17 Jul 2006, Marco van de Voort wrote: 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 :-) 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 10:50:33AM +0200, Michael Van Canneyt wrote: - 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 :-) Library hell exists on all platforms. Running from it is futile. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 11:21:36AM +0200, Micha Nelissen wrote: 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. I don't understand this. Afaik there is no difference at all. Could 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 :-)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 11:19:22AM +0200, Jonas Maebe wrote: 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). It generates ld parameters, not gcc parameters. So you don't have to parse them unless you want to use an internal linker. Thnks, will improve the text for the wiki. Not that it changes much, don't like an external called from the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 11:59, Marco van de Voort wrote: It generates ld parameters, not gcc parameters. So you don't have to parse them unless you want to use an internal linker. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 12:21, Daniël Mantione wrote: 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. IMHO crap like *_config are only tricks used by C people used to work around defficiencies in their toolchains. 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. 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. The whole point of the *config stuff is exactly to be resistant against that. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 12:33, Jonas Maebe wrote: 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 can 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). 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. The whole point of the *config stuff is exactly to be resistant against that. Against name changes of course. Supporting the multiple *config stuff could happen via a linklib-like statement in the unit sources. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 12:16:10PM +0200, Jonas Maebe wrote: 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'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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Marco van de Voort wrote: 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. I don't understand this. Afaik there is no difference at all. Could you be more elaborate in what you think would go wrong automatically? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 13:42, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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. 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). 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:03, Daniël Mantione wrote: 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. You could support exactly the same in C with some #pragma statements in the header files. This is implementation-specific rather than language specific. 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). 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. 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: Marco van de Voort wrote: 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. I don't understand this. Afaik there is no difference at all. Could you be more elaborate in what you think would go wrong automatically? 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. 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 matter at all. Moreover 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 01:57:01PM +0200, Jonas Maebe 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. 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? 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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Marco van de Voort wrote: On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: 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. This is not for inbetween releases, since not all software will be automatically recompiled in all cases. 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) ? And in this case specifically it doesn't matter at all. What doesn't matter and why ? Moreover source and binary packages can be used together (and in practice, are), and there are build clusters (pointy hat) that check this. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:31, 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 do not understand this last part. Are you talking about dynamically loading libraries at run time or so? 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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
On 17 Jul 2006, at 14:03, Daniël Mantione wrote:
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.
You could support exactly the same in C with some #pragma statements in the
header files. This is implementation-specific rather than language specific.
In that case, there exists no need for gtk-config at all.
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).
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.
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).
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.
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.
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___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 14:57, Daniël Mantione wrote:
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).
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.
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.
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.
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.
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.
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.
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___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 02:35:41PM +0200, Micha Nelissen wrote: Marco van de Voort wrote: On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote: 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. This is not for inbetween releases, since not all software will be automatically recompiled in all cases. 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) ? 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. Moreover source and binary packages can be used together (and in practice, are), and there are build clusters (pointy hat) that check this. What do they check ? building all 13000 packages. 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 :-). 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
On 17 Jul 2006, at 14:57, Daniël Mantione wrote:
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).
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.
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).
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.
The whole point of the *config scripts it that you do not have to care about
such implementation details at all.
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.
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.
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.
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.
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.
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.
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.
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).
This we agree on, the compiler should do the work.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 16:01, Daniël Mantione wrote:
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).
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.
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).
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.
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.
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.
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.
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.
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).
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Jonas Maebe wrote: On 17 Jul 2006, at 16:01, Daniël Mantione wrote: 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. 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:03, 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Mon, Jul 17, 2006 at 04:37:07PM +0200, Jonas Maebe wrote:
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.
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).
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...
That would be a pity, since OS X is the se 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).
It is inevitable. But that doesn't mean there is only one way to integrate
stuff. It must be done cautiously, and pragmatic.
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.
Of course making the developer type in everything manually is always
more generic and less work for us.
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: 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.
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.
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 KR'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
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 17 Jul 2006, at 22:36, Marco van de Voort wrote:
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).
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.
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.
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.
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).
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...
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.
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.
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 starts at 10.4).
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.
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.
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.
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.
That was Almindor not me.
I was replying to a mail from Daniel.
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.
That's more or less what I'm saying below, which you are refuting.
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?
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
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
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
On Ne, 2006-07-16 at 16:09 -0400, Bob wrote:
-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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
