I'm thinking about creating an ebuild for the gentoo linux distrubution. This (for those who don't know) is a distro which builds everything from source. An Ebuild automates this process. (in short it will add a number of users (and hopefully developers)).

I've looked over the doc's and the faq and the downloads, and I've followed the mailing list. In short I'm rather confused as to what is needed. Do I need FPC Version 1.07 as in the downloads, or 1.08 as in the the mailing list, or 1.1 as in the downloads. Where is the best place to download it from?

How about the Lazarus. It looks like it is in heavy development right now (which I feel is good), am I better grabbing source from the cvs or from the download section?

Should I hold off until 1.08 fpc is officially released?

Is there a document somewhere that explains exactly how to install from source? (I'm not interested in binaries).

Chris Bruner

I'd been seeing some "Unable to create Pipe" exceptions when making repeated calls to TProcess so I set up a test case. Dropping a TProcess, button and an edit on a form and running the following code reproduces the problem. On my system it fails on call 326. Setting "options:=[];" executes all 50000 calls without error.

procedure TForm1.Button1CLICK(Sender: TObject);
var i:Integer;
begin
  With Process1 do
    Begin
      commandline:='ls';
      options:=[pousepipes,ponoconsole];
      For I:=1 to 50000 do
        Begin
          edit1.text:=inttostr(i);
          active:=true;
          WaitonExit;
        end
    End
end;

Although this probably isn't related, bracketing the CreateProcess call with a "try" at line 698 and "finally" at line 707 in process.pp would close the pipes and dispose of FEnv's memory even if the exception at line 706 were taken.

-Tom

Hi, i use 1.1 from the Lazarus download section on a Suse 8.1 and it works fine but i must make OPT=-dNoGdkPixBufLib 1.07 will not work for me.

What is the problem with 1.0.7?

Mattias

Both 1.0.7 and 1.0.8 wil work. Current 1.1 does not work. You can try a later version of 1.1. For example the one provided on the website.

How about the Lazarus. It looks like it is in heavy development right now (which I feel is good), am I better grabbing source from the cvs or from the download section?

The daily snapshot or even better the cvs version of today is more stable and advanced than the rpms/debs in the download section. The rpms/debs will be updated when 1.0.8 is released.

Should I hold off until 1.08 fpc is officially released?

Good question. The 1.0.8 is now releasing one month. I hope it will not take another one.

Is there a document somewhere that explains exactly how to install from source? (I'm not interested in binaries).

There is a basic docs/INSTALL text. It should explain a few things. Please help to improve it.

Mattias

If you replace "make" with "gmake" everywhere, yes.

But better do it for *nix in general, replace make everywhere with $MAKE and say in the notes that $MAKE=make on linux and $MAKE=gmake on *BSD, and $MAKE=<GNU MAKE> whatever it is called on other OSes.

A lot of the path/prefix stuff also goes for e.g. Slackware (and maybe debian/BSD and gentoo), or people that do customised installations, or have a certain separation in privileges (e.g. if you try to make a debian installation where power users can install apps, but are not root, the default Linux installation also can be to simplistic)

It is more a more advanced Unix filesystem hierarchy, than BSD specific.

Probably the pipes are not closed when the executed program finishes, this would explain why the system stops: there is a limit on the number of pipes you can create.

I will have a look at it tonight, no linux available ATM...

Michael.

I've thought this over for FreeBSD. Effectively, you need:

- a file with all sources, or two (fpc and lazarus) (1) e.g. for fpc ftp://ftp.freepascal.org/fpc/dist/Linux/separate/sources.tar preferably an export (no CVS/ dirs). The above file misses this (2) Lazarus source snapshot. Not available on the net (?)
- _any_ starting compiler from the 1.0 branch) You can do a check by parsing the output of ppc386 -i if it is 1.0.6 .. 1.0.8 it is ok.
- dependant packages. (for FreeBSD that is gtk12, glib12 and gdk_pixbuf and GNU make, iconv and gettext)

FPC build:

(1) (fetch) necessary files (FPC source, starting compiler) (2) (extract) Then de-tgz in work directory,
(3 (build) enter work/fpc/ and run

make all OPT='-gl -O3p3' PP=/path/to/startingcompiler-name-ppc386

(/path/to/ can be omitted when ppc386 is in the path)

(4) (install) then, again in work/fpc, run
make install PP=compiler/ppc386 PREFIX=$THEPREFIX

(THEPREFIX= usually is /usr/lcoal, but e.g. on NetBSD it is /usr/pkg for ports)

Create a symlink
ln -s $THEPREFIX/lib/fpc/1.0.8/ppc386 $THEPREFIX/bin/ppc386

install sourceinstall PREFIX=$THEPREFIX

(5) (configure) run compiler/utils/samplecfg $THEPREFIX/lib/fpc/1.0.8 $ETCDIR (6) (optional, test), see if ppc386 -i gives output, else give a warning that user need to add $PREFIX/bin to his current path. Try to compiler a program with -viwn, and see if that gives errors.

Notes:
- If you need package lists, you need to generate or supply them yourself, (in the port, or in an extra archive)
either way,
do a dummy install to /tmp/pack and determine the files installed with find . >ll

- $THEPREFIX and $ETCDIR should be user configurable. Otherwise local installs aren't possible.
- BSDHIER=1 on all make commands forces BSD hierarchy conventions, test what is closer to Gentoo defaults, with or without.
- make a user with very limited rights (e.g. by not making him member of "users"), and try if he can install in his local dir without errors.

- Binutils and some other utils needed during built are in base in FreeBSD, so I don't check/know these dependancies.
Easiest is to try the port on a minimal Gentoo install with lots of verbosity options, and see if it works.

How about the Lazarus. It looks like it is in heavy development right now (which I feel is good), am I better grabbing source from the cvs or from the download section?

Lazarus is easier I think.
Make sure the proper source snapshot (so a lazarus cvs checkout), and all needed libraries.

Then repeat the build and install steps for lazarus/

Should I hold off until 1.08 fpc is officially released?

Yes and no.

Yes, for submitting anything final, wait for the final sources. No, you can start experimenting now.

Is there a document somewhere that explains exactly how to install from source? (I'm not interested in binaries).

There is a make cycle faq, but that's for a more ackward era. The makefiles have improved a lot, and basically it is calling make all and make install with the appropriate modifiers. The releases are roughly prepared in a similar way.

Can I add this text to docs/INSTALL for BSD?

See lazarus downloads section 'Sources'.

Mattias

Hi,
i use 1.1 from the Lazarus download section on a Suse 8.1 and it works fine but i must make OPT=-dNoGdkPixBufLib
1.07 will not work for me.

greets harry

My education continues....

And you need it ;-)

Ok, and true. Most of the changes will be very internal. Most bugfixes in the 1.0.x branch usually are.

I am shocked that FPC doesn't use 's normal. The usual documentation sketches a quite rosy picture, and

most people react that way. There are good reasons though, see below for a selection. Most people consider them reasonably

More then that FPC doesn't use any C code to build itself.

Why would it need it? C is not "special" in anyway. Pascal is better even.

Is this by design?

Of course it is. 50-100 MB source don't fall out of thin air. The project has been running for a decade.

Why avoid all that good code?

Are you so sure it actually _is_ good code? :-) And more important, from the perspective of somebody not really interested in C?

The main reasons for not doing a gcc port:

- _Historical_ gcc was not stable and cleaned up enough when FPC was concieved.

- _Non Unix origin_ FPC originated on Dos, and got cleaned up after. Unix _and_ platforms are just like the others. Choices made for Unix can be hard on other platforms. Emulations make non Unix ports feel "fat", non-native and emulation like. Example: cygwin. Dos and Windows are really major ports. OS/2 also still has a steady following

- _manpower_ The gcc integration costs a lot of work. Adapting to other peoples changes, working with patches, maintaining compability with a very complicated build process, not breaking other people work and the complexity of regression testing that comes with that etc. FPC has grown till about 10 main developpers and several hardworking people submitting units, maintaining OS ports, building snapshots daily etc. It did most of its existance with less than a third of that manpower.

- _language_ Pascal is what we do. Modding gcc would mean the core team would _have to_ work in C. No option, at least not until I get paid. The Pascal code (think big here. 50 till over 100 MB FPC compilable code in CVS and in some related projects) is also a kind of testsuite. It forces one to use the compiler.

- _Bootstrapping_ and crosscompiling issues are much easier than most outsiders expect. Often even easier due to smaller dependancies (both libraries and tools used in the build). You saw yourself, essentially you need as,ld ,make and a start compiler to build the entire tree. And some platforms even eliminate AS.
- _bloat_ gcc has a lot of unnecessary features, code and provisions. This again costs a lot of maintenance, raises some limitations etc.

- _multi language?_ gcc is primary a C compiler, the rest is duct-taped on. Provisions like units are alien to it.
This also goes for the separation of parts of the suite too (preprocessor
- fronten - backend - backend assembler - backend linker), buildprocess etc all tailored to C and C'ish languages. E.g. we are unable to smartlink lazarus, simply because the linker eats an estimated amount of 1.5 Gb to generate the 10-20 MB magnitude Lazarus binary. C does only some minor smartlinking, so it isn't very optimised :-) We would have more of this tool related problems in the gcc case.

- _control_ using gcc is giving-up control. For a pascal specific major change you have to negotiate with really big commercially funded teams (with fulltime people calling the shots), from a totally inferior negotiating position. (you don't have anything crucial they want, and the C crowd is even _Pascal unfriendly_, and that is an understatement). If you go the way people want it, add libc, cpp autoconf/make, yacc lex, and whole deal more also to this list of "negotiating partners". This point shouldn't be underestimated, and for me might be the most important one, together with *nix centic view of the gcc scheme. Even though I'm a BSD user for over a decade now.

Example: imagine if you _really_ need some change in the main gcc code in order to fix or create some major part of your infrastucture. Assume you are in say about 1/2 a year before the head branch of gcc splits of the next release branch. e.g. one branch will receive new major features and changes to become gcc5 in time, the other one will stabilize to become gcc4 in say about a year. If they don't wnat to incorporate your code for gcc4 because of stability reasons, schedules or simply being uninterested, you are stuck with it till gcc5 comes out. (say minimally 3 years from now), that time you are stuck with patches or hopeless workarounds severely hampering your development.

All this also hampers having a working version early, which is useful to get contributors. (the ones that really put in manyears are the ones that are the most rare)

Also compare the state of GPC (GNU Pascal which is gcc based) with FPC, and realise that GPC is 1 and 1/2 times as old, a bit more even, and has full GNU backing. This is partially due to their non standard Pascal dialect choice also, but still...

There are also disadvantages:
- the "good" code in gcc that simply isn't worth the trouble, but still has to be reimplemented: codegenerators for a lot of processors, optimizers.
- inability to interface to headers of the other gcc languages natively, most notably C, C++ and Objective C. (the last one because a major Mac OS X api is based on it)

----------
The libc issue

The libc thing is a bit different. I still think choosing syscalls was a good choice at the time because

- libc activity instability and libc->glibc transition.
- different versions on a lot of distro's
- again buildprocess complications.
- programs that don't use libraries are only slightly larger, and
- It's not just libc, but also libm, libgcc etc. However this is a trend that might be a reason to do it in the end.
- Headers have to be translated and kept up to date. The few functions we use from libc in some cases are much easier to maintain. Binary interfaces like the kernel rarely change.
- other unices use other libc's. That means a header translation per OS, not one for all with a few ifdef's.
- the total lack of support to make such usage easier for non C compiler derivates or C like languages Most unices fail to have a master set of headers in a abstract, easy parsable format from which other headers could be easily generated. Even Windows does this a bit by providing a version of its newer modules in IDL.

This might change in near-middle the future (by setting a define when recompiling FPC) to switch the default to use libc as back end on *nix.

Main reasons:
- the free unices are more stable, there is some unification and standarisation process going on.
- OS X. For various reasons it was decided to keep to libc, mainly because Apple can change the kernel interfaces easier. This also means we have some basic infrastructure for the change in place.
- the tendancy to put more functionality in (merge libs with) libc. This is bad IMHO, however a fact. (think userland threading libs, NIS and other multi-machine authentication support, unicode, internationalisation).
- FPC is more advanced, the avg programs have become more complex, and longterm quite a lot will link to C libraries and therefore libc anyway. (e.g. lazarus because of gtk.)
- keep the syscall interface, because it makes small stuff and bootstrapping so much easier.

I assume there is a provision for FPC to interface with C isn't there?

Of course it can. How do you think lazarus interfaces with gtk?

But the exact answer depends how you see it. You can't use C headers and simply try to call the functions listed in them. You'd have to convert the headers to their pascal equivalent, and there are some semi automatic ways. Then you can link to C. Look for the existing headers (like the gtk interface that lazarus uses)

The fact that library and OS teams don't have any abstract (so non C) headers that can be easy auto-ocnverted makes this unnecessary painful. However that is not our choice, but the relevant teams.

So it is like having a mold (headers to use with C programs), but not be able to use it to make some special form (Pascal programs). However by looking at the original mold, you can make a better fitting one for the special form.

Linking directly (as opposed to via C or the C++ CEXTERN or what its called way ) with C++ and Objective C is not possible yet. Some other languages might be possible through their C compability.

You can of course try to revert to asm to write the interface. It is the only other language that FPC directly supports.

The fact that C and C++ are such horrible languages to implement also prohibits the possibility to make a simple C subset compiler part of FPC, just to get at the headers.

___

(Marco V is really tired now)

I hope I showed you a bit of what is behind the commonly presented idealistic view of Linux and Unix in general.

If you have more questions related to this, I'd be happy to answer them.

There is no C code in FPC !!

My point (rather badly made I admit) is that there are standard ways of installing software, and it appears that fpc (and lazarus by extension) do not follow that standard. So any hopes of getting more people involved are

But ./configure is also only C specific most times. For perl you need 'perl Makefile.PL'.

Ofcourse we can add a dummy ./configure script that does nothing.

Peter

What I want.
tar -xzf fpc*
cd fpc
.configure
make
make install

tar -xzf lazarus*
cd lazarus
.configure
make (make works for pascal as well)
make install

What I've got:
Downloading the fpc source files from the download area gives me deb files? Downloading source files from fpc site gives me much source but no obvious way to compile it.
Using the install scripts in the install directory (after following the instructions) breaks with permissions problems on programs that don't even seem to exist.
Nothing seems to work.

Maybe I'm just totally going down the wrong path. This isn't my first time trying to install this beast, and I would really like to use and possibly help with development, but I can't even get to stage 1.

I will look for "There is a basic docs/INSTALL text."

However the only docs that I could find on site were ones that were autogenerated for the pascal sources. Nothing to do with install.

What my plan is...
The game Seige of Avalon is being open sourced in order to move it to Linux. I'm going to be involved with that. The game was originally written in Delphi for Windows. I would like to get Lazarus put on my system along with fpc so that I can use it instead of Kylix. If this happens from the beginning of the port it will keep things compatible. (instead of a big messy clean up later). By creating an ebuild I can get any gentoo users to be able to quickly and easily install fpc and lazarus. I can then go off and work on the port of the game.

This has nothing to do with that. FPC only use about 50 primitives from the kernel, that would be otherwise used from libc.

It doesn't matter for memory usage where I get them. The kernel is also resident it seems.

So in theory the kernel interface could be beneficial even. Unused parts of the libc can be swapped out when a heavy FPC program is running.

I think, the current free pascal concept (avoiding C libraries, mainly libc) is usable only because on a tipical system only a few pascal processes run at once; the rest of the system is written in C, so enough memory remains to run the pascal programs :)

The main reason why this is important is for OS tools, like the shell and make. They are often called recursively. But if one of them were FPC based, you'd have a 100kb redundancy with a FPC rtl shared lib, and the C ones. Big deal :-)

Don't forget we only need a very small subset of libc, (say 10-40 kb of it's 800). The rest is not OS library, but C language runtime, which we can't use anyway.

Again, theory and practice in Unix advocacy are WIDE apart ;-)

My education continues....

:)

I thought for sure that I saw some C files. OK so I need FPC installed before I install FPC. I understand that now. I'll start again from scratch tonight and make notes of what I do. (and were I had to backtrack). I'm going to try for fpc 1.0.8 from the CVS since it is so near release any differences between what I get and what the release is should presumably be small.

I am shocked that FPC doesn't use then that FPC doesn't use any C code to build itself. Is this by design? Why avoid all that good code? I assume there is a provision for FPC to interface with C isn't there?

Chris Bruner

Of course it does.

I can see your point, except if all you support are system calls, you will need to support each different system's calls. If you support a libraries interface then that interface doesn't change for the major functions. (strcpy hasn't changed for years!)

The 'C declaration' not really, no, but often you see things like

extern char * __strcpy() etc etc
#define strcpy __strcpy

which means that the REAL entry point into the library is __strcpy. The C programmer does not 'see' this, but an external pascal program does... and you can give a lot of examples where this is so.

As a matter of fact one of the libraries jobs is to hide the differences between the different operating systems.

This is theoretically so, and that is why FPC tries to define a cross-platform RTL interface.

In practice, however, many libraries are horribly system dependent.

This is why GNU tools as ./configure and automake and the like exist.

If you can't think of a use for the C library, then why do you ask us to use it ? ;-)

Michael.

But shared libraries also create more complex situations. For releasing stand-alone software it is not recommended. See the problems with the QT bindings of Kylix, you still need a second QT installation.

To create workable shared libraries with FPC the compiler needs to support PIC. Search the fpc-devel mailinglist archives for an explanation why it is needed.

Peter

Marco van de Voort wrote

> My education continues.... And you need it ;-)

Don't be nasty, self depreciating humor does not need sarcasm 8P

I was shocked because there is so much code available for use, it seems like re-inventing the wheel.

> More then that FPC doesn't use any C code to build itself. Why would it need it? C is not "special" in anyway. Pascal is better even.

C is special in that it is pervasive. I agree that pascal is a better language, so let's not fight about that.

The code has been worked on for more then 3 decades...

The main reasons for not doing a gcc port:

<big snip>

That was a lot of typing to argue against doing a gcc port. (which was not at all what I had in mind). I was thinking more of building the fpc compiler using tools like flex and bison etc to handle the parsing, and making a mini compiler which could be used to make the main fpc. I wasn't at all considering making gcc and fpc one in the same.

I have yet to experience this :)

I wouldn't consider that a disadvantage, it's simply a way of extending fpc's reach. (or am I misunderstanding you).

I've got to be misunderstanding something. If you are able to do a syscall, why can't you do a lib call? Isn't it a case of translating a C header into a pascal header and linking it in? (I think there's code out there somewhere to handle this).

That's what I thought, but I was beginning to wonder.

OK, this is what I expected.

The fact that library and OS teams don't have any abstract (so non C) headers that can be easy auto-ocnverted makes this unnecessary painful. However that is not our choice, but the relevant teams.

I think the C version is an abstract version. Just not the abstract you would prefer :)

Nice analogy.

Well OpenGL, SDL sound libraries are some of the libraries that immediatly spring to mind. Although I know that Jedi-sdl is in fact a pascal library to do those three things.

(Marco V is really tired now)

I'm tired just reading it!

I hope I showed you a bit of what is behind the commonly presented idealistic view of Linux and Unix in general.

Well I must confess that I commonly use the tool-chain for C C++, Java, python and perl. I just assumed that it would work for Pascal as well.

If you have more questions related to this, I'd be happy to answer them.

No I think I've had enough education in this area for now. :) My background is Windows (C/C++/Delphi/turbo pascal v2 on) and Linux (C/C++,python).

Thanks for taking the time to write this huge response.

Chris Bruner

_________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

> > In fact, to be able to compile Kylix programs, I am now converting the

C

> > library headers to a unit. So you will have the full power of the C

library

All I'm trying to do just now is install it :) Why would I need the C library for that if it doesn't use it? This whole discussion came about when I asked about using configure make etc. I was just surprised that you wouldn't use it. Now that you've given me the #define strcpy __strcpy I can see your point. Still it seems like wheel reinventing, but I do see your point.

Chris

I hate outlook. After spending 1/2 an hour replying, it crashed before sending the message...

All in all the gist of what I was saying is that I can understand your reasoning and although I was surprised to find you didn't use the libraries, I can see now why you didn't.

Chris

In practice, you will have to for libc too. Not all libc's are alike. And in practice, most syscalls are quite universal.

The only that differ are the ones that have 64-bit arguments and returnvalues. This is minutes work.

And opendir/readdir/closedir, since they have a large userland portion for speed. (iow, the kernel call getdents/getdirentries is much moer lowlevel than the libc opendir/readdir/closedir. This is an exception though). This is something more involved.

If you support a libraries interface then that interface doesn't change for the major functions. (strcpy hasn't changed for years!)

We are talking about OS functionality of libc. strcpy is not interesting for us, since that is part of the C handling, which we don't even need. And btw, it is prefered to use a bounded version nowadays.

As a matter of fact one of the libraries jobs is to hide the differences between the different operating systems.

Don't forget that I can't access the library in the way it is meant to be, because I can't access headers. So the part of this hiding that is done via headers is already lost.

Ok. No problem. Developpers always like people that think about such things :-)

As mailclient I can recommend ELM. I use it for 10 years now :-)

That mantra is overrated. Like in the real world, reuse is often many times more expensive than writing your own. Not to mention that the analogue would be to slap a wheel from a bus under your Ferrari.

I tried to give you some of the reasons.

Sure, but that doesn't bring anything as soon as you only use it as vehicle to build another language. Except the headers, but they are already discussed thoroughly

I agree that pascal is a better language, so let's not fight about that.

I don't really hate C.

Unix might, but not anything *nix related.

No. gcc and libc (the first tools from the GNU stable) date mid-late eighties. FPC early nineties, and used Turbo Pascal to bootstrap (maybe 1.0 might still be able to do that), which is older, and more stable than gcc by far at that time, and available on dos.

And remember that pre 1992-1994 internet access was quite different. Harder to get, no web etc.

If there are old Unix sources in Linux, that won't take long anymore, with that SCO lawsuit (admitted, there will be some early BSD code from say mid eighties in it)

Pascal is basically a LL(1) language, and FPC is a variation on that, and use the for Wirth traditional top down parsers, usually handcrafted. Flex and bison are targeted to generate LALR bottop up parsers.

making a mini compiler which could be used to make the main fpc.

What would be the advantage of that? The compiler is a 700k static binary already. Also keep in mind that the compiler uses OOP, so that the subset of the minicompiler would be fairly large.

We have one compiler per architecture. Crosscompiling for other OSes only needs cross-binutils, the appopriate FPC rtl and libraries, if you need them. Nothing more.

For *BSD <-> other *BSD <-> linux crosscompiling I don't even do that for "small" programs (this includes the 6 MB source compiler).

Compile on Linux with the BSD rtl, copy to freebsd, brandelf, ready. With normal binutils.

Crosscompiling for a different processor needs a real crosscompiler and a RTL and binutils for the target. However, this crosscompiler is again only a 700kb static binary.

Moreover the binary fpc can hide it, so as say FPC has 5 architectures, there are 5 binaries (e.g. ppc386, ppcppc, ppc68k, ppcsparc ppcalpha) that compile for the give architecture. One (the native one) is normal, the rest is cross.

fpc -Palpha <the rest of the parameters will make "fpc" call the corresponding binary (ppcalpha) and give the parameters.

Header conversion is pain. As said before, it could be much less painful if there were something else, more abstract set header other then C headers to start with. The reasons for that are the macro tricks etc.

This is even a problem under C. Configure exists because of it, just to compile small programs and pry the result apart, in order to get info from the headers, as one can't do it automatically. If you include the headers they are preprocessed and loose a lot of info.

In assembler you can do everything. Nowadays we can also make lib calls. (the problems were alignment, calling conventions etc)

The library interface is simply more in a state of flux than the kernel.

Also with the library usually you have to take the whole package. (like e.g. threading in a way compatible with libc) While with the kernel you can take primitives and build your own system on top of it.

Isn't it a case of translating a C header into a pascal header and linking it in? (I think there's code out there somewhere to handle this).

Hardly. The tools only work with reasonably clean headers, and usually are written to process a specific (clean) set of headers. Sometimes they generate unreadable output.

The *nix OS headers simply use a too large subset of both the language and preprocessor to adequately convert them automatically. (as in e.g. a kind of configure step) The same for most of the packages, though some are reasonably clean, but all different.

The win32 headers are much better in that respect. I hope the Linux standarisation together with the diminishing amount of Unices in active development will improve this somewhat.

I hear QT has a scheme with a perl script that generates headers from an abstract representation. I really hope that caches on (except the use of Perl:-)

The main problem is that each team writes its own headers with its own style. The language it too complex to process fully automatical and get decent output. It is a bit like decompiling. Possible under certain conditions, but you won't like what you get.

No, I wouldn't call C .h an abstract header, at least not done as under *nix. It describes the C data structures that map to the structure they want to have. It doesn't the describe the structure itself.

- You can't derive e.g. usage of a SET (which is an abstact structure) from the header.
- Which param is IN/OUT/INOUT from .c/.h?
- Strings and their bounds. What is the upperbound of the pchar?
- Under FPC we have OOP. We can't use these features if the base representation doesn't grasp the concepts.

There are FPC specific versions of both libraries. OpenGL even comes with FPC.

Bad guess :-)

> If you have more questions related to this, I'd be happy to answer them. No I think I've had enough education in this area for now. :) My background is Windows (C/C++/Delphi/turbo pascal v2 on) and Linux (C/C++,python).

I've been using BSD (later FreeBSD) on the university (and later at home) for a decade now, half of which working with Pascal, and half of which with Modula2, another Wirthian language.

I used both languages under Dos (and a bit Windows) too.

I think, the current free pascal concept (avoiding C libraries, mainly libc) is usable only because on a tipical system only a few pascal processes run at once; the rest of the system is written in C, so enough memory remains to run the pascal programs :)

I think, it is not a problem to make the most of RTL as a library itself. FCL is more difficult, but some tricks might help (just build a ppas.sh and link.res, build all fcl .o files from link.res to a .so, and then link the rest program). I have mostly succeed linking such a binary one time, but failed many times. May be, it is possible to place this mechanism.
And, besides, this will be one of the important solutions when anyone will try to make a special fpc-based OS.

I think the point was that the libs are so. (shared object). Whereas fpc is static. (please correct me if I'm wrong!) If you have many fpc programs each will have it's own copy of the library in memory. This probably hasn't become an issue since most often you only use one or two fpc programs at a time, but what happens when you have a large app that uses litereally thousands of instances of a fpc program. Does that mean that there is thousands of instances of the same code in memory? The kernel will be so busy swaping out processes that nothing would get done.

Chris

you wrote

What I want. tar -xzf fpc* cd fpc .configure

We don't need to detect what kind of Pascal flavour is installed so the configure step is not needed.

There are deb files available. When 1.0.8 is released it will also be uploaded to debian. I already contacted the debian maintainer for this. But we dependent on him to do the real upload

Downloading source files from fpc site gives me much source but no obvious way to compile it.

Unzip/untar the sources and run 'make install' and everything is build and installed with the prefix /usr/local. 'make build' will only build everything and doesn't install. 'make linuxzip' will build the tar.gz files, just like the linux release has. 'make deb' will build .deb with the current date in the version number. 'make rpm' will build the .rpm files.

Peter

If you can't think of a use for the C library, then why do you ask us to use it ? ;-)

Well, I can :)

Libraries are loaded into the memory only once, no matter how many processes use them. Thus the memory used for the library is shared. This heavily reduces memory needs for a system.

I think, the current free pascal concept (avoiding C libraries, mainly libc) is usable only because on a tipical system only a few pascal processes run at once; the rest of the system is written in C, so enough memory remains to run the pascal programs :)

Pista

The point that FPC is written in itself has already been made, but...

Another shock might be that FPC doesn't use libc, but interfaces with Linux (the kernel) itself.

My point (rather badly made I admit) is that there are standard ways of installing software, and it appears that fpc (and lazarus by extension) do not follow that standard.

There is no standard on Linux. There are only provisions for C programs that follow some scheme, nothing more. If you step outside it, there is no support.

FPC supports multiple platforms not just *nix. You could also say th

There are no Pascal headers (or something that they could be produced from except from manual labour), no generic installers nothing.

Configure is nothing but a large patchy shellscript to query a standard C compiler. It is nothing to do with the OS.

So any hopes of getting more people involved are immediatly stunted.

Most people by far use binary packages on *nix. In general FPC's system is much more userfriendly than the routine, it is

The rule of thumb should be, as you are move from doing things in the "normal/standard" way it should be documented more and more carefully to keep the level of obviousness from disappearing over the horizon.

Till now, most developpers quickly got the hang of it. Maily also because the core developpers are on the diverse lists to provide direct one-on-one tips.

Still some more documentation to the buildproces would be nice, but it seems that you've already missed the make cycle faq (which is a sub-page of the real faq?) It is outdated, but addresses the issues somewhat. I'll see if I can update it a bit with the info I wrote earlier on the list.

(and keep in mind my horizons as a non-user are quite different then you as someone who has gotten things working).

I started that way too :-)

The fpc is compiled from C as well as assembler so it would be useful.

My point (rather badly made I admit) is that there are standard ways of installing software, and it appears that fpc (and lazarus by extension) do not follow that standard. So any hopes of getting more people involved are immediatly stunted. The rule of thumb should be, as you are move from doing things in the "normal/standard" way it should be documented more and more carefully to keep the level of obviousness from disappearing over the horizon. (and keep in mind my horizons as a non-user are quite different then you as someone who has gotten things working).

I would be happy to help in this regard, but I'm stuck.

Chris Bruner

files?

There are deb files available. When 1.0.8 is released it will also be uploaded to debian. I already contacted the debian maintainer for this.

But

we dependent on him to do the real upload >Downloading source files from fpc site gives me much source but no

obvious

the

I think the point was that the libs are so. (shared object). Whereas fpc is static. (please correct me if I'm wrong!)

Ok. No, FPC is not entirely static, but the shared library provisions (see ppc386 -? option -CD -XD) are spartan, and a bit problematic because of the fact that PIC misses.

This is known, but the reason is not that we dislike shared linking, but that there are certain assumptions in the codegenerator which are quite hard to change in the 1.0.x branch, which limit the ability to implement full blown shared linking.

They are scheduled for the major next version (the 1.1 branch, whatever the release number will be), where the codegenerator is rewritten because of multiple processor support. PIC should be possible now in 1.1, but is not yet implemented.

I do think that keeping the binaries static in principle is the way to go for FPC, since most people will do that. But the shared RTL+FCL etc will only increase the distro by about a MB, and that will be compressed, so I think that when implemented, 1.1.x default FPC installs can generated shared linked programs.

Personally I think there will be three libraries.

1. rtl,
2. some units + fcl,
3. rest of packages.

but there hasn't been discussion yet about this.

If you have many fpc programs each will have it's own copy of the library in memory. This probably hasn't become an issue since most often you only use one or two fpc programs at a time, but what happens when you have a large app that uses litereally thousands of instances of a fpc program.

Then it depends what you want. Memory or speed. Loading files that are shared linked is slower.

Does that mean that there is thousands of instances of the same code in memory? The kernel will be so busy swaping out processes that nothing would get done.

It can happen yes. But it is a per machine decision, depending on load, the programs in question etc.

P.s. maybe it is wise to move this thread to fpc-devel?

And have to update each time the libc interface somehow changes ? No thanks ! It can usually be hidden for C programmers with some macro tricks, but not for FPC. Not to mention that there may be differences between various platforms... (irresistably, I am forced to think of MS Windows ;-) )

Doesn't fpc support ifdef? I can see your point, except if all you support are system calls, you will need to support each different system's calls. If you support a libraries interface then that interface doesn't change for the major functions. (strcpy hasn't changed for years!) As a matter of fact one of the libraries jobs is to hide the differences between the different operating systems.

In fact, to be able to compile Kylix programs, I am now converting the C library headers to a unit. So you will have the full power of the C library at your disposal if you so desire...

I can't think of an immediate use, but I'm sure it will come in handy.

Chris

And have to update each time the libc interface somehow changes ? No thanks ! It can usually be hidden for C programmers with some macro tricks, but not for FPC. Not to mention that there may be differences between various platforms... (irresistably, I am forced to think of MS Windows ;-) )

So we want the compiler and fpc programs to be able to run independent of any C library.

Of course, this doesn't mean you cannot use C libraries (or THE C library);
Lazarus wouldn't exist otherwise: they use GTK.

In fact, to be able to compile Kylix programs, I am now converting the C library headers to a unit. So you will have the full power of the C library at your disposal if you so desire...

Michael.

That was a lot of typing to argue against doing a gcc port. (which was not at all what I had in mind). I was thinking more of building the fpc compiler using tools like flex and bison etc to handle the parsing,

The parsing isn't the difficult thing in a compiler.

Of course, we could. But there are so much flavours of libc outside that we decided to use syscalls instead of libc. Just try to run a Hello world in C++ compiled and as usual dynamic linked e.g. on a SuSE 8.x on e.g. a RH 7.x ... I guess nobody knows for sure if this works. A FPC compiled Hello world requires nothing than a kernel with elf support...

cryst wrote

The fpc is compiled from C as well as assembler so it would be useful.

No it isn't. The FPC is compile with the FPC. Maybe that is your confusion. The development environment does not exist on the machine unless they install FPC. Unlike alot of projects that use gcc you only need to install the source to do the build. To build FPC you must HAVE FPC. You need to at least install the release binary to rebuild FPC.

Wouldn't it be more logical to report those bugs 'upstream'? Ie. I am not going to distribute my own version of lazarus...but I report bugs here on the mailinglist (or somewhere).

Thanks for the info,

Micha.

Peter Vreman wrote

But shared libraries also create more complex situations. For releasing stand-alone software it is not recommended. See the problems with the QT bindings of Kylix, you still need a second QT installation.

Isn't that because of licensing, or am I way off here? You have to link against the borland library because the license says so. You may not link only against the QT libraries.

Regards,

Micha.

No no, this is not the issue.
Borland made some changes to the Qt libraries (bugfixes) to make sure it works with Kylix. You can still use a vanilla Qt library, by setting an environment variable before application startup.