Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-05

darwin - rtl include files

28 messages · 9 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mattias Gaertner

The unit baseunix.pp is available for darwin powerpc (fpc 2.1.1). I guess FPC_USE_LIBC is disabled for this target, so it seems to include {$i bsyscall.inc}.
But it seems there is no such file for darwin. Only

./freebsd/i386/bsyscall.inc
./freebsd/x86_64/bsyscall.inc
./linux/arm/bsyscall.inc
./linux/i386/bsyscall.inc
./linux/powerpc64/bsyscall.inc
./linux/powerpc/bsyscall.inc
./linux/sparc/bsyscall.inc
./linux/x86_64/bsyscall.inc
./linux/m68k/bsyscall.inc

Where is the mistake?

Mattias

Reply by email

Mattias Gaertner
to Marco van de Voort
Show quoted text 7 lines
... > I guess FPC_USE_LIBC is disabled for this target, ... > Where is the mistake? See above. Jonas choose to only implement FPC_USE_LIBC for Darwin.

Thanks.
AFAIK darwin has a libc, but FPC does not provide a unit for it. Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. Right?

Is there a somewhere a list of the flags set in the FPC sources?

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote
> See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. Thanks.

Actually, libc is the only supported system interface for Mac OS X/ darwin (system calls are undocumented and change all the time, even between minor OS revisions). Libc is also guaranteed to be forward compatible (i.e., the situation that a program will not run anymore on a future OS release because it uses a symbol which no longer exists in a new libc, will not happen on Mac OS X unless there is a bug, which will then be fixed by Apple)

AFAIK darwin has a libc,

There are several libc's for almost any OS out there.

but FPC does not provide a unit for it. Right?

The libc unit is only provided for Linux/x86 for Kylix compatibility. Use unix/baseunix instead, which works on all *nix OS'es.

And the FPC_USE_LIBC is set for all rtl sources under darwin. Right?

Yes.

Is there a somewhere a list of the flags set in the FPC sources?

I don't think so.

Jonas

Reply by email

Marco van de Voort
to Mattias Gaertner: On Tue, 16 May 2006 15:31:16 +0200 (CEST) Thanks. AFAIK darwin has a libc, but FPC does…
Show quoted text 10 lines
(Marco van de Voort) wrote: > ... > > I guess FPC_USE_LIBC is disabled for this target, > ... > > Where is the mistake? > > See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. Thanks. AFAIK darwin has a libc, but FPC does not provide a unit for it.

FPC doesn't provide a unit for /Unix etc define what you get, and how that unit is implemented is not defined, dynlibs the same for shared libs etc.

In practice there are two basic implementations; syscalls and getting access to the needed functions by linking to libc.

Right? And the FPC_USE_LIBC is set for all rtl sources under darwin.

Yes. Note that it can also be set for Linux and FreeBSD (though that might require some minimal maintainance)

Right?

Yes. But I still have no clue what you are exactly looking for. Maybe I could give you more direct hints if you said what you actually need :-)

see also (the bit outdated) docs I made while working on the unix rtl: http://www.stack.nl/~marcov/unixrtl.pdf
http://www.stack.nl/~marcov/buildfaq.pdf
http://www.stack.nl/~marcov/porting.pdf

Is there a somewhere a list of the flags set in the FPC sources?

No. Not like that. They often change.

Reply by email

Mattias Gaertner
to Marco van de Voort
Show quoted text 36 lines
> (Marco van de Voort) wrote: > > ... > > > I guess FPC_USE_LIBC is disabled for this target, > > ... > > > Where is the mistake? > > > > See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. > > Thanks. > AFAIK darwin has a libc, but FPC does not provide a unit for it. FPC doesn't provide a unit for /Unix etc define what you get, and how that unit is implemented is not defined, dynlibs the same for shared libs etc. In practice there are two basic implementations; syscalls and getting access to the needed functions by linking to libc. > Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. Yes. Note that it can also be set for Linux and FreeBSD (though that might require some minimal maintainance) > Right? Yes. But I still have no clue what you are exactly looking for. Maybe I could give you more direct hints if you said what you actually need :-) see also (the bit outdated) docs I made while working on the unix rtl: http://www.stack.nl/~marcov/unixrtl.pdf http://www.stack.nl/~marcov/buildfaq.pdf http://www.stack.nl/~marcov/porting.pdf > Is there a somewhere a list of the flags set in the FPC sources? No. Not like that. They often change.

That's exactly my problem.
How to keep the codetools up2date? How can they find the right include paths and unit paths?
Using fpmake is difficult, as a lazarus compiled with fpc 2.0.2 should be able to parse the fpc 2.1.1 fpmake files, which might use newer functions.

Mattias

Reply by email

Michael Van Canneyt
to Mattias Gaertner
Mattias Gaertner wrote 43 lines
On Tue, 16 May 2006 15:51:43 +0200 (CEST) (Marco van de Voort) wrote: >> (Marco van de Voort) wrote: >>> ... >>>> I guess FPC_USE_LIBC is disabled for this target, >>> ... >>>> Where is the mistake? >>> >>> See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. >> >> Thanks. >> AFAIK darwin has a libc, but FPC does not provide a unit for it. > > FPC doesn't provide a unit for /Unix etc define what > you get, and how that unit is implemented is not defined, dynlibs the same > for shared libs etc. > > In practice there are two basic implementations; syscalls and getting > access to the needed functions by linking to libc. > >> Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. > > Yes. Note that it can also be set for Linux and FreeBSD (though that might > require some minimal maintainance) > >> Right? > > Yes. But I still have no clue what you are exactly looking for. Maybe I > could give you more direct hints if you said what you actually need :-) > > see also (the bit outdated) docs I made while working on the unix rtl: > http://www.stack.nl/~marcov/unixrtl.pdf > http://www.stack.nl/~marcov/buildfaq.pdf > http://www.stack.nl/~marcov/porting.pdf > >> Is there a somewhere a list of the flags set in the FPC sources? > > No. Not like that. They often change. That's exactly my problem. How to keep the codetools up2date? How can they find the right include paths and unit paths?

IMHO:
Eventually, you'll have to switch to parsing the .ppu files for some parts.

Michael.

Reply by email

Marco van de Voort
to Mattias Gaertner: On Tue, 16 May 2006 15:51:43 +0200 (CEST) That's exactly my problem. How to keep the…
Show quoted text 10 lines
(Marco van de Voort) wrote: > > Is there a somewhere a list of the flags set in the FPC sources? > > No. Not like that. They often change. That's exactly my problem. How to keep the codetools up2date? How can they find the right include paths and unit paths? Using fpmake is difficult, as a lazarus compiled with fpc 2.0.2 should be able to parse the fpc 2.1.1 fpmake files, which might use newer functions.

Well. Most includes are not as drastic as FPC_USE_LIBC. And FPC_USE_LIBC has this meaning since 1.9.2. Moreover, it doesn't influence paths, only includefile names.

But I see the problem, one could install a FPC_USE_LIBC linux rtl (so deviating from the default) and build Lazarus on top of this. How would lazarus know this?

Most logical would be to store the conditionals that pkg is compiled with in package.fpc ?

Reply by email

Mattias Gaertner
to Michael Van Canneyt: IMHO: Eventually, you'll have to switch to parsing the .ppu files for some parts. Michael.
Show quoted text 51 lines
On Tue, 16 May 2006, Mattias Gaertner wrote: > On Tue, 16 May 2006 15:51:43 +0200 (CEST) > (Marco van de Voort) wrote: > >>> (Marco van de Voort) wrote: >>>> ... >>>>> I guess FPC_USE_LIBC is disabled for this target, >>>> ... >>>>> Where is the mistake? >>>> >>>> See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. >>> >>> Thanks. >>> AFAIK darwin has a libc, but FPC does not provide a unit for it. >> >> FPC doesn't provide a unit for /Unix etc define >what > you get, and how that unit is implemented is not defined, dynlibs >the same > for shared libs etc. >> >> In practice there are two basic implementations; syscalls and getting >> access to the needed functions by linking to libc. >> >>> Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. >> >> Yes. Note that it can also be set for Linux and FreeBSD (though that >might > require some minimal maintainance) >> >>> Right? >> >> Yes. But I still have no clue what you are exactly looking for. Maybe I >> could give you more direct hints if you said what you actually need :-) >> >> see also (the bit outdated) docs I made while working on the unix rtl: >> http://www.stack.nl/~marcov/unixrtl.pdf >> http://www.stack.nl/~marcov/buildfaq.pdf >> http://www.stack.nl/~marcov/porting.pdf >> >>> Is there a somewhere a list of the flags set in the FPC sources? >> >> No. Not like that. They often change. > > That's exactly my problem. > How to keep the codetools up2date? How can they find the right include > paths and unit paths? IMHO: Eventually, you'll have to switch to parsing the .ppu files for some parts.

Huh? Can you give an example?

Mattias

Reply by email

Michael Van Canneyt
to Mattias Gaertner
Mattias Gaertner wrote 56 lines
On Tue, 16 May 2006 16:11:43 +0200 (Romance Daylight Time) Michael Van Canneyt wrote: > > > On Tue, 16 May 2006, Mattias Gaertner wrote: > >> On Tue, 16 May 2006 15:51:43 +0200 (CEST) >> (Marco van de Voort) wrote: >> >>>> (Marco van de Voort) wrote: >>>>> ... >>>>>> I guess FPC_USE_LIBC is disabled for this target, >>>>> ... >>>>>> Where is the mistake? >>>>> >>>>> See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. >>>> >>>> Thanks. >>>> AFAIK darwin has a libc, but FPC does not provide a unit for it. >>> >>> FPC doesn't provide a unit for /Unix etc define >> what > you get, and how that unit is implemented is not defined, dynlibs >> the same > for shared libs etc. >>> >>> In practice there are two basic implementations; syscalls and getting >>> access to the needed functions by linking to libc. >>> >>>> Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. >>> >>> Yes. Note that it can also be set for Linux and FreeBSD (though that >> might > require some minimal maintainance) >>> >>>> Right? >>> >>> Yes. But I still have no clue what you are exactly looking for. Maybe I >>> could give you more direct hints if you said what you actually need :-) >>> >>> see also (the bit outdated) docs I made while working on the unix rtl: >>> http://www.stack.nl/~marcov/unixrtl.pdf >>> http://www.stack.nl/~marcov/buildfaq.pdf >>> http://www.stack.nl/~marcov/porting.pdf >>> >>>> Is there a somewhere a list of the flags set in the FPC sources? >>> >>> No. Not like that. They often change. >> >> That's exactly my problem. >> How to keep the codetools up2date? How can they find the right include >> paths and unit paths? > > IMHO: > Eventually, you'll have to switch to parsing the .ppu files for some > parts. Huh? Can you give an example?

All info you need is in the .ppu file ? Function/Method names, arguments etc ?

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt
Show quoted text 9 lines
[...] >> IMHO: >> Eventually, you'll have to switch to parsing the .ppu files for some >> parts. > > Huh? Can you give an example? All info you need is in the .ppu file ? Function/Method names, arguments etc ?

I spotted the missing file, because I was browsing the sources to see, how it is implemented.
The interfaces were ok, the implementation not. .ppu won't help here.

Mattias

Reply by email

Florian Klaempfl
to Marco van de Voort: Well. Most includes are not as drastic as FPC_USE_LIBC. And FPC_USE_LIBC has this meaning…
Marco van de Voort wrote 19 lines
> (Marco van de Voort) wrote: >>> Is there a somewhere a list of the flags set in the FPC sources? >> No. Not like that. They often change. > That's exactly my problem. > How to keep the codetools up2date? How can they find the right include paths > and unit paths? > Using fpmake is difficult, as a lazarus compiled with fpc 2.0.2 should be > able to parse the fpc 2.1.1 fpmake files, which might use newer functions. Well. Most includes are not as drastic as FPC_USE_LIBC. And FPC_USE_LIBC has this meaning since 1.9.2. Moreover, it doesn't influence paths, only includefile names. But I see the problem, one could install a FPC_USE_LIBC linux rtl (so deviating from the default) and build Lazarus on top of this. How would lazarus know this? Most logical would be to store the conditionals that pkg is compiled with in package.fpc ?

Well, the point is, you could get all source pathes from the currently valid ppus.

Reply by email

Daniël Mantione
to Micha Nelissen

Op Tue, 16 May 2006, schreef Micha Nelissen:

Show quoted text 7 lines
On Tue, 16 May 2006 16:11:43 +0200 (Romance Daylight Time) Michael Van Canneyt wrote: > IMHO: > Eventually, you'll have to switch to parsing the .ppu files for some parts. Do .ppu files tell in what source file and what line a symbol is defined ?

Yes. However, I fear that reasing ppu files will be troublesome because the file format changes often.

Daniël

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 8 lines
>> Most logical would be to store the conditionals that pkg is compiled with in >> package.fpc ? > > Well, the point is, you could get all source pathes from the currently > valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus.

You don't need the sources. The .ppu contains everything you need.

Michael.

Reply by email

Vincent Snijders
to Michael Van Canneyt
Michael Van Canneyt wrote 16 lines
On Wed, 17 May 2006, Marco van de Voort wrote: >>> Most logical would be to store the conditionals that pkg is compiled >>> with in >>> package.fpc ? >> >> Well, the point is, you could get all source pathes from the currently >> valid ppus. > > If they are compiled on this system? Most people use precompiled FPC in > combination with lazarus. You don't need the sources. The .ppu contains everything you need.

They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations?

Vincent.

Reply by email

Michael Van Canneyt
to Vincent Snijders
Vincent Snijders wrote 22 lines
Michael Van Canneyt schreef: > > > On Wed, 17 May 2006, Marco van de Voort wrote: > >>>> Most logical would be to store the conditionals that pkg is compiled >>>> with in >>>> package.fpc ? >>> >>> Well, the point is, you could get all source pathes from the currently >>> valid ppus. >> >> If they are compiled on this system? Most people use precompiled FPC in >> combination with lazarus. > > You don't need the sources. The .ppu contains everything you need. > They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations?

According to daniel: yes

But you should separate 2 things:
- Provide feedback (tooltips, code completion)
- View actual sources.

For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time...

Michael.

Reply by email

Daniël Mantione
to Michael Van Canneyt

Op Wed, 17 May 2006, schreef Michael Van Canneyt:

Show quoted text 10 lines
On Wed, 17 May 2006, Vincent Snijders wrote: > They don't contain implementation in human readable form. For example if > I have the TComponent.Name property, I want to be able to jump to > TComponent.SetName method declaration and then to the implementation. You > need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes

It is because the entire symbol table is in the ppu file. As you can see in the declaration of Tsym in symtype.pas, the fileposinfo stores the source locations. There is of course a lot more information available, which can be put to good use.

Daniël

Reply by email

Jonas Maebe
to Micha Nelissen: On Tue, 16 May 2006 15:50:28 +0200 So an application linked against any future version of…
Micha Nelissen wrote 6 lines
> between minor OS revisions). Libc is also guaranteed to be forward > compatible (i.e., the situation that a program will not run anymore So an application linked against any future version of libc is guaranteed to work also against the current version ?

No, it's the other way round. But Apple does distribute SDK's for older OS releases which you can build against, so your application will run on them too.

Jonas

Reply by email

Mattias Gaertner
to Michael Van Canneyt: According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips,…
Show quoted text 37 lines
On Wed, 17 May 2006, Vincent Snijders wrote: > Michael Van Canneyt schreef: >> >> >> On Wed, 17 May 2006, Marco van de Voort wrote: >> >>>>> Most logical would be to store the conditionals that pkg is compiled > >>>>> with in >>>>> package.fpc ? >>>> >>>> Well, the point is, you could get all source pathes from the >currently >>> valid ppus. >>> >>> If they are compiled on this system? Most people use precompiled FPC >in >> combination with lazarus. >> >> You don't need the sources. The .ppu contains everything you need. >> > > They don't contain implementation in human readable form. For example if > I have the TComponent.Name property, I want to be able to jump to > TComponent.SetName method declaration and then to the implementation. > You need sources for that. Does the ppu provide (relative) source > locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time...

Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed.
IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority.

Mattias

Reply by email

Michael Van Canneyt
to Mattias Gaertner
Mattias Gaertner wrote 43 lines
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt wrote: > > > On Wed, 17 May 2006, Vincent Snijders wrote: > >> Michael Van Canneyt schreef: >>> >>> >>> On Wed, 17 May 2006, Marco van de Voort wrote: >>> >>>>>> Most logical would be to store the conditionals that pkg is compiled >> >>>>>> with in >>>>>> package.fpc ? >>>>> >>>>> Well, the point is, you could get all source pathes from the >> currently >>> valid ppus. >>>> >>>> If they are compiled on this system? Most people use precompiled FPC >> in >> combination with lazarus. >>> >>> You don't need the sources. The .ppu contains everything you need. >>> >> >> They don't contain implementation in human readable form. For example if >> I have the TComponent.Name property, I want to be able to jump to >> TComponent.SetName method declaration and then to the implementation. >> You need sources for that. Does the ppu provide (relative) source >> locations? > > According to daniel: yes > > But you should separate 2 things: > - Provide feedback (tooltips, code completion) > - View actual sources. > > For the first, the .ppu is enough. In Delphi 'Find declaration' also > doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable.

The format is such that you can always read older/newer .ppu files: there are just certain types of blocks which you can't handle.

While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority.

I don't quite agree about this 'nice to have', but you're doing all the work, so you are right :-)

Michael.

Reply by email

Daniël Mantione
to Michael Van Canneyt

Op Wed, 17 May 2006, schreef Michael Van Canneyt:

Show quoted text 17 lines
> > > source > > > locations? > > > > According to daniel: yes > > > > But you should separate 2 things: > > - Provide feedback (tooltips, code completion) > > - View actual sources. > > > > For the first, the .ppu is enough. In Delphi 'Find declaration' also > > doesn't work half the time... > > Reading .ppu files is definitely planned for the codetools. But as Daniel > pointed out: If the .ppu format changes all ppu become unreadable. The format is such that you can always read older/newer .ppu files: there are just certain types of blocks which you can't handle.

I think reading ppu files can be done reliably with the help of some meta data that describes the structure of the record. If you read a record from ppu, things will break if we change record. However, with some metadata that would get updated if the record changes an IDE would be able to get to the data reliably.

The funny thing is that the compiler already generates such metadata: Runtime Type Information. However, it is burried in the compiler executable, and smartlinked away, so RTTI is currently not usable for this purpose.

Daniël

Reply by email

Peter Vreman
to Mattias Gaertner: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Reading .ppu files is…
Show quoted text 51 lines
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt wrote: > > > On Wed, 17 May 2006, Vincent Snijders wrote: > > > Michael Van Canneyt schreef: > >> > >> > >> On Wed, 17 May 2006, Marco van de Voort wrote: > >> > >>>>> Most logical would be to store the conditionals that pkg is > compiled > > > >>>>> with in > >>>>> package.fpc ? > >>>> > >>>> Well, the point is, you could get all source pathes from the > >currently >>> valid ppus. > >>> > >>> If they are compiled on this system? Most people use precompiled FPC > >in >> combination with lazarus. > >> > >> You don't need the sources. The .ppu contains everything you need. > >> > > > > They don't contain implementation in human readable form. For example > if > > I have the TComponent.Name property, I want to be able to jump to > > TComponent.SetName method declaration and then to the implementation. > > You need sources for that. Does the ppu provide (relative) source > > locations? > > According to daniel: yes > > But you should separate 2 things: > - Provide feedback (tooltips, code completion) > - View actual sources. > > For the first, the .ppu is enough. In Delphi 'Find declaration' also > doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority.

This is incorrect, the generic .ppu format didn't change for the last several years. The code needed to parse ppu's and retrieve symbol info is also stable for the last years. See how good an old ppudump works on current ppu files. The changes in the ppu are only at the end of the entries and doesn't influence the start of the entries that contain the name and location.

Reply by email

Mattias Gaertner
to Peter Vreman
Show quoted text 58 lines
> On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) > Michael Van Canneyt wrote: > >> >> >> On Wed, 17 May 2006, Vincent Snijders wrote: >> >> > Michael Van Canneyt schreef: >> >> >> >> >> >> On Wed, 17 May 2006, Marco van de Voort wrote: >> >> >> >>>>> Most logical would be to store the conditionals that pkg is >> compiled >> > >> >>>>> with in >> >>>>> package.fpc ? >> >>>> >> >>>> Well, the point is, you could get all source pathes from the >> >currently >>> valid ppus. >> >>> >> >>> If they are compiled on this system? Most people use precompiled >FPC > >in >> combination with lazarus. >> >> >> >> You don't need the sources. The .ppu contains everything you need. >> >> >> > >> > They don't contain implementation in human readable form. For example >> if >> > I have the TComponent.Name property, I want to be able to jump to >> > TComponent.SetName method declaration and then to the implementation. >> > You need sources for that. Does the ppu provide (relative) source >> > locations? >> >> According to daniel: yes >> >> But you should separate 2 things: >> - Provide feedback (tooltips, code completion) >> - View actual sources. >> >> For the first, the .ppu is enough. In Delphi 'Find declaration' also >> doesn't work half the time... > > Reading .ppu files is definitely planned for the codetools. But as > Daniel pointed out: If the .ppu format changes all ppu become > unreadable. While if > an include path changes in the FPC sources, only a few files can't be > browsed. > IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources > has > higher priority. This is incorrect, the generic .ppu format didn't change for the last several years. The code needed to parse ppu's and retrieve symbol info is also stable for the last years. See how good an old ppudump works on current ppu files. The changes in the ppu are only at the end of the entries and doesn't influence the start of the entries that contain the name and location.

Great. Then I will take a look.

Mattias

Reply by email