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
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
> 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
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
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.
> > >
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 platfo
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 chan
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
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
standar
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 anot
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.
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 um
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
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 fo
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
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 can
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
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.
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 b
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
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 libgt
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 mu
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
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 el
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 i
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.fr
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
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 de
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
> 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
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 compile
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 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
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 AFAI
On 17 Jul 2006, at 10:04, Marco van de Voort 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
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 f
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
> 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 w
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 wh
> 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 li
> 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 syst
-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
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 n
-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
43 matches
Mail list logo
