Forwarded from: marcov@stack.nl (Marco van de Voort)
A.s. reproduction to list allowed.
The Ncurses author is Michael van Canneyt, however most other FPC authors contributed to it, and we don't have a sign away rights to a foundation system. Be sure to get ncurses from current CVS, and don't use e.g. 1 1/2 year old 1.0.10 sources.
CVS is open for anonymous use, and there is also a webinterface development page: http://www.freepascal.org/develop.html webcvs ncurses dir: http://www.freepascal.org/cgi-bin/viewcvs.cgi/fpc/packages/extra/ncurses/
FPC used to have an own version of the LGPL (which we still call LIBRARY GPL btw), from before LGPL existed. Somewhere in 2000 this was rectified, but because users felt incertain about some of the clauses, an additional clarification to the base LGPL text was added, which is quoted below:
---------------------------------------------------------------------------- This is the file COPYING.FPC, it applies to the Free Pascal Run-Time Library (RTL) and packages (packages) distributed by members of the Free Pascal Development Team.
The source code of the Free Pascal Runtime Libraries and packages are distributed under the Library GNU General Public License (see the file COPYING) with the following modification:
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you a are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
If you didn't receive a copy of the file COPYING, contact: Free Software Foundation 675 Mass Ave Cambridge, MA 02139 USA
Frank,
Thanks very much for the helpful info on location of fpc copying rights and on location of current version. (I don't know how they find stuff in the fpc archives, packages, sources...) I'm very glad to now be working from the most recent source version.
One construction I'm not sure on translation of is:
function beep:longint; cdecl;external libncurses; function can_change_color:bool; cdecl;external libncurses; function cbreak:longint; cdecl;external libncurses;
The fpc "cdecl;' makes the calling sequence of Pascal match that of c. (see the table from FPC manual at end of this email; its a graphic file, sorry, I couldn't get a good text cut.) It appears 'cdecl' is the default for gpc (true?), thus, for gpc I think these could be declared, somewhat like the external variables were, as, e.g.:
function beep:longint; external libncurses;
However, gpc does not like the library name after external and gives the error
... error: syntax error before `libncurses'
So I can resolve the syntax error by shortening it to just:
function beep:longint; external;
But I'm left wondering why the prior author thought he needed to specify the libncurses...
So, two questions: 1. Am I correct in assuming that no parallel to FPC's 'cdecl' is needed for calls from GPC to C? 2. Is there a way to specify the library source for a function call, as it is done with external variables? Or, conversely, can I assume that this isn't needed?
Thanks,
Willett Kempton
On 14 Mar 2005 at 3:48, willett wrote:
Frank,
Thanks very much for the helpful info on location of fpc copying rights and on location of current version. (I don't know how they find stuff in the fpc archives, packages, sources...) I'm very glad to now be working from the most recent source version.
One construction I'm not sure on translation of is:
function beep:longint; cdecl;external libncurses; function can_change_color:bool; cdecl;external libncurses; function cbreak:longint; cdecl;external libncurses;The fpc "cdecl;' makes the calling sequence of Pascal match that of c. (see the table from FPC manual at end of this email; its a graphic file, sorry, I couldn't get a good text cut.) It appears 'cdecl' is the default for gpc (true?), thus, for gpc I think these could be declared, somewhat like the external variables were, as, e.g.:
function beep:longint; external libncurses;However, gpc does not like the library name after external and gives the error
... error: syntax error before `libncurses'
That is Delphi and BP syntax. GPC does not support that syntax.
So I can resolve the syntax error by shortening it to just:
function beep:longint; external;
Yes. Better still is: function beep:longint; external name 'beep';
But I'm left wondering why the prior author thought he needed to specify the libncurses...
Because that is correct Delphi syntax.
So, two questions:
- Am I correct in assuming that no parallel to FPC's 'cdecl' is needed for calls from GPC to C?
Who knows? But this should solve your problem with cdecl: {$ifdef __GPC__} {$define cdecl attribute(cdecl)} {$endif}
- Is there a way to specify the library source for a function call, as it is done with external variables? Or, conversely, can I assume that this isn't needed?
Not needed. Simply do this: {$L ncurses}
What you are likely to have problems with (in future GPC versions) is that, you should use "external name 'foo'" instead of just "external". If you don't specify the name of the external symbol, GPC allocates a default. The warnings indicate that the default may be problematic, and that there will be no warnings in future versions.
BTW: I have a version of ncurses.pp that compiles under GPC. But there are linker problems, both under Windows and Linux when you try to comple a test program. It is the same one: "undefined reference to `_acs_map'".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
willett wrote:
Frank,
Thanks very much for the helpful info on location of fpc copying rights and on location of current version.
That was Marco actually. I only forwarded his mail, as he isn't suscribed to the list.
One construction I'm not sure on translation of is:
function beep:longint; cdecl;external libncurses; function can_change_color:bool; cdecl;external libncurses; function cbreak:longint; cdecl;external libncurses;The fpc "cdecl;' makes the calling sequence of Pascal match that of c. (see the table from FPC manual at end of this email; its a graphic file, sorry, I couldn't get a good text cut.) It appears 'cdecl' is the default for gpc (true?),
Yes.
thus, for gpc I think these could be declared, somewhat like the external variables were, as, e.g.:
function beep:longint; external libncurses;However, gpc does not like the library name after external and gives the error
... error: syntax error before `libncurses'So I can resolve the syntax error by shortening it to just:
function beep:longint; external;
But I'm left wondering why the prior author thought he needed to specify the libncurses...
I don't know FPC so well. I remember in BP you had to specify the library for each declaration. Under Unix this seems unnecessary (independent of the compiler, as long as it uses a standard linker, which they all do AFAIK), since the linker figures it out by itself.
Also note that `longint' is probably wrong. Apparently FPC sticks to the BP sizes where it's 32 bit.
In GPC, we have exact counterparts for all C types. Since the C result type of `beep' is `int', you should use `CInteger' here. If it was `long', it would be `MedInt'. (See the GPC manual for a translation table.)
If the FPC unit translates both to `longint' (because both happen to be 32 bit on IA32), you'll have to look at the C code to find the correct type, otherwise the unit won't be portable.
Frank
-
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
willett