There is no Mac OS X Quickstart section in the install/doc/readme.txt file,
although needed, in particular for the ReadMe.txt File of Mac OS X .dmg package.
This is my suggestion, which is partly based on what I found in
install/macosx/resources/ReadMe.txt:
*
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
I tried doing a "make deb" from the fixes_2_0 branch and I got an error. The
log info is below:
===
/usr/bin/make -C fpcm all
grep: /etc/ld.so.conf: No such file or directory
make[4]: Entering directory
`/home/jpmugaas/fpcbuild_fixes_2_0/build/fpc-2.0.4/utils/fpcm'
make[4]: Leaving directory
`/
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
On 7/17/06, ik <[EMAIL PROTECTED]> wrote:
OT (more or less), I wish to create a very important mod for Apache
that will divide error log based on virtual host. Do you know a good
resource to use ? Does the current translated mod_example, can help me
achieve that ?
I do plan to create some tutor
OT (more or less), I wish to create a very important mod for Apache
that will divide error log based on virtual host. Do you know a good
resource to use ? Does the current translated mod_example, can help me
achieve that ?
Ido
On 7/17/06, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
H
Hello,
The headers are now available for download. The are explanations about
how to make a simple module, example code, internal details and a
download link of the bindings here:
http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules
I translated mod_example from apache source c
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
Hi,
Does FPC have the headers converted for Xft support under *nix
systems? I couldn't find it, so created a unit that uses Xft it my
freepascal apps. Could I create a patch and send it to the mailing
list to apply to FPC?
If it is ok, where should in live? /src/packages/extra/xft ?
Regards
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 Mon, 17 Jul 2006, Den Jean wrote:
Hi,
MSE created some patches for fpc 2.0.4 rc1
to fix some widestring and db issues.
http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/
I seems they are not applied to rc2.
Can someone with widestring and db knowledge
of fpc dev
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
Den Jean wrote:
Hi,
> MSE created some patches for fpc 2.0.4 rc1
> to fix some widestring and db issues.
> http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/
>
> I seems they are not applied to rc2.
.
.
Thanks for this information. There's been no decision made in the
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
Den Jean wrote:
> Hi,
>
> MSE created some patches for fpc 2.0.4 rc1
> to fix some widestring and db issues.
> http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/
>
> I seems they are not applied to rc2.
>
> Can someone with widestring and db knowledge
> of fpc dev take
Hi,
MSE created some patches for fpc 2.0.4 rc1
to fix some widestring and db issues.
http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/
I seems they are not applied to rc2.
Can someone with widestring and db knowledge
of fpc dev take a look at this?
It would be nice
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
Just a little suggestion... I think we should inform any progress of FPC
development on the website. Maybe this has been informed through the Wiki, but I
believe not every visitor have time to look at the Wiki. Just like what Firebird
project does, they inform every RC on the website.
Just my
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 7/17/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
Fixed in trunk. r4238 in case sb wants to merge it.
Damn that was quick! Thanks.
Graeme.
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
> The win32 API call, GetStartupInfo() fails under FPC with {$Mode
> Delphi} and no preceding @ sign in the parameter. Under Delphi 7 you
> can call GetStartupInfo as show below.
Fixed in trunk. r4238 in case sb wants to merge it.
___
fpc-devel mailli
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
ik wrote:
Hi Ido,
> errore.msg keep on changing (and that's a good thing). The problem is
> that the people who translate it to other languages should be notified
> about any changes, so we could add them to the translated version as
> well, instead of diffing the errore.msg to with our copy ...
> 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
Hi,
The win32 API call, GetStartupInfo() fails under FPC with {$Mode
Delphi} and no preceding @ sign in the parameter. Under Delphi 7 you
can call GetStartupInfo as show below.
-- Delphi [System.pas]
procedure GetStartupInfo(var lpStartupInfo: TStartupInfo); s
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
Hi,
errore.msg keep on changing (and that's a good thing). The problem is
that the people who translate it to other languages should be notified
about any changes, so we could add them to the translated version as
well, instead of diffing the errore.msg to with our copy ...
So I have a request t
> 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
53 matches
Mail list logo
