Hi
I have seen a funny thing when running a crt program in the msys environment, using pdcurses-2.6.
This is the program: program Foo; uses crt; var i: Integer; begin clrscr; for i := 1 to ParamCount do WriteLn (ParamStr (i)) end.
This is the weird error I get when I run the program: "LINES value must be >= 2 and <= 1: got 1 initscr(): LINES=1 COLS=1: too small."
If I do "export LINES=25" and run the program again, I get: "LINES value must be >= 2 and <= 1: got 25 initscr(): LINES=25 COLS=1: too small."
If I do "export COLS=80" and run the program again, I get: "LINES value must be >= 2 and <= 1: got 25"
Obviously there is a problem somewhere. How can a value be ">=2" while being "<=1" at the same time? This is a new mathematical experience for me!
Any clues?
Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Some Apple docs say that for some cases of binary backwards compatibility, I need to define external functions as weak_import so that the linker will not complain. It is done like:
extern int SayHello() __attribute__((weak_import));
Normally, this would translate to:
function SayHello: int; external name 'SayHello'; attribute(weak_import);
But the weak_import is not recognized by GPC.
Is there a way to do this in GPC?
Thanks, Peter.
Some Apple docs say that for some cases of binary backwards compatibility, I need to define external functions as weak_import so that the linker will not complain. It is done like:
extern int SayHello() __attribute__((weak_import));
Normally, this would translate to:
function SayHello: int; external name 'SayHello'; attribute(weak_import);
But the weak_import is not recognized by GPC.
GCC has a "weak" attribute for ELF targets, but it is not the same as the "weak_import" attribute for Mac OS X. As far as my knowledge goes, the "weak_import" attribute is currently in the Apple version of gcc only. Nevertheless, it is in the process of being merged into gcc-3.4., see http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00320.html
Another question is whether gpc will automatically recognize the attribute as soon as it is in the back-end.
Maybe, you can solve the linking problem by "weak-linking" the whole framework of library you are using (see the "ld" man page).
Regards,
Adriaan van Os
Adriaan van Os wrote:
Another question is whether gpc will automatically recognize the attribute as soon as it is in the back-end.
It should do so (via decl_attributes ()).
Frank
Prof. A Olowofoyeku (The African Chief) wrote:
I have seen a funny thing when running a crt program in the msys environment, using pdcurses-2.6.
This is the program: program Foo; uses crt; var i: Integer; begin clrscr; for i := 1 to ParamCount do WriteLn (ParamStr (i)) end.
This is the weird error I get when I run the program: "LINES value must be >= 2 and <= 1: got 1 initscr(): LINES=1 COLS=1: too small."
If I do "export LINES=25" and run the program again, I get: "LINES value must be >= 2 and <= 1: got 25 initscr(): LINES=25 COLS=1: too small."
If I do "export COLS=80" and run the program again, I get: "LINES value must be >= 2 and <= 1: got 25"
Obviously there is a problem somewhere. How can a value be ">=2" while being "<=1" at the same time? This is a new mathematical experience for me!
It doesn't say it can be, only that it must be. ;-)
Well, the code in PDCurses-2.6/win32/pdcscrn.c says:
fprintf(stderr,"LINES value must be >= 2 and <= %d: got %d\n", csbi.dwMaximumWindowSize.Y, internal->lines);
So, apparently csbi.dwMaximumWindowSize.Y is wrong. It seems to be set a few lines above in
GetConsoleScreenBufferInfo(hConOut, &csbi);
This seems to be a Windows call, so I don't know anything about it, and even if I did, I couldn't debug it. But perhaps it'll help you find out something ...
Frank
On 8 Nov 2003 at 2:12, Frank Heckenbach wrote:
[...]
Obviously there is a problem somewhere. How can a value be ">=2" while being "<=1" at the same time? This is a new mathematical experience for me!
It doesn't say it can be, only that it must be. ;-)
Well, the code in PDCurses-2.6/win32/pdcscrn.c says:
fprintf(stderr,"LINES value must be >= 2 and <= %d: got %d\n", csbi.dwMaximumWindowSize.Y, internal->lines);So, apparently csbi.dwMaximumWindowSize.Y is wrong. It seems to be set a few lines above in
GetConsoleScreenBufferInfo(hConOut, &csbi);
This seems to be a Windows call, so I don't know anything about it, and even if I did, I couldn't debug it. But perhaps it'll help you find out something ...
I have since ascertained that this problem only happens in the MSYS rxvt terminal. Everything works fine at a windows command prompt, and even when bash is loaded directly from the command prompt. Ncurses works well in all situations. So I guess that it might be better to define USE_NCURSES automatically under MSYS.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
-
Adriaan van Os -
Frank Heckenbach -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)