Jeff Weeks wrote

Do I really need to use vgalib under linux?

It depends what you want to do?

Jeff Weeks wrote

Do I really need to use vgalib under linux? I'm having a hard time finding a supported graphics card. Is it true that only a handful of chipsets are supported? Any way to use the X graphics rather than vgalib?

use svgalib instead.

Michael

Do I really need to use vgalib under linux? I'm having a hard time finding a supported graphics card. Is it true that only a handful of chipsets are supported? Any way to use the X graphics rather than vgalib?

Yes, look for the SDL headers (Jedi-SDL), or use plain OpenGL.

Do I really need to use vgalib under linux? I'm having a hard time finding a supported graphics card. Is it true that only a handful of chipsets are supported? Any way to use the X graphics rather than vgalib?

Can't get graphics to work on my Trident 9660. It's the oldest chipset I have. I'm looking on Ebay for a replacement.

Is this it?

* VGA
* EGA
* ARK Logic ARK1000PV/2000PV
* ATI VGA Wonder
* ATI Mach32
* Cirrus 542x, 543x
* OAK OTI-037/67/77/87
* S3 (limited support)
* Trident TVGA8900/9000
* Tseng ET3000/ET4000/W32

Actually, that list was indeed for svgalib and I'm using svgalib.

The files are still named libvga.config, etc, but hey are svga.

Jeff

I need to use graphics mode. Text works fine but I need to do some graphing, etc.

Jeff

I realized I'm using an older version of SVGALIB.

1.4.3 adds a few important chipsets.

Jeff

I tried the SDL4Freepascal headers and they seem to work. Just can't see how to display text. And they don't appear to work on Macintosh. JEDI-SDL supposedly works on a "modified" version of Freepascal on a Mac.

Any Mac people out there using JEDI-SDL? Anyone have Freepascal examples?

Thanks.

Jeff

Not yet on a Mac, but I had most examples running on FreeBSD.

They are in cvs under projects/contrib/sdl

The main problem is currently that you have to change the Darwin system unit, by renaming the "main" procedure in rtl/bsd/system.pp to "SDLMain" and then recompile the system unit. Of course, afterwards that system unit is only usable to create SDL programs.

So we have to implement a way to specify the name of the routine when compiling the program, but that means it must be moved to the main program and "generated" inside the compiler. Because it receives parameters, this is non trivial (unless I hardcode the parameter locations, but that's dirty and non-portable).

Jonas

I'd like to try using JEDI-SDL but the directions only tell how to set up the IDE... not how to use the command line compiler under Linux.

I'm stumped on a few of them.

I condensed the following from the JEDI-SDL Yahoo Group instructions and added what I think the corresponding command-line switch should be:

Compiler switches page

Delphi 2 extensions to ON
Delphi compatibility to ON

-Mobjfpc
-Mdelphi

-------------------------------------------------
These I have no idea!!

Assembler Reader to Intel style Assembler
Assembler Output to precoff.

Add FPC to the conditional defines box at the bottom of the page.  
----------------------------

Options | Linker.

Preferred Library Type to Smart Libraries.

The closest thing I could find for this is:

-CX create also smartlinked library
-----------------------------

Options | Directories.

Unit directories box add path to where JEDI-SDL units exist.

USE -Fi

Hello,

-Mobjfpc and -Mdelphi are different things and mutually exclusive (when given as compiler switch).

I guess that -Mdelphi is appropriate.

-Rintel

Assembler Output to precoff.

Probably this means pecoff, not precoff:

-Apecoff

Don't think that this compiler switch is required in this case. It just controls the output format - In this case generates win32 pe coff files, which is probably not suitable for a Linux environment.

Add FPC to the conditional defines box at the bottom of the page.

-dFPC

Should be correct.

Yes.

Regards,
Thomas

-MDelphi nowadays auto turns on -Rintel too

FPC already defines FPC as internal symbol.

Can't you add the SDLMain to the darwin sdl units and let this call main? Or is main defined twice then because the sdllib contains a main?

Florian Klaempfl wrote

Can't you add the SDLMain to the darwin sdl units and let this call main? Or is main defined twice then because the sdllib contains a main?

Yes. And for some reason, the linker picks the main of our system unit to execute instead of the one in libsdl. I don't know on what basis it does this. The reason it doesn't trigger a duplicate symbol error is that the Mac OS X linker works with a two-level name space: all libraries have their own symbol namespace (although you can disable this for legacy *nix compatibility using an environment variable).

Jonas

04-09-03 13.12, skrev Jonas Maebe följande:

Can it help by changing the link order ? Or it is not possible wiht a 2 level ns.. ?

Olle

Hmm, yes, that's probably it. The two-level namespace is the reason that the order of the libraries and objects on the command line matters under Darwin... We'd have to introduce some compiler switches to influence the order in which the compiler passes the objects and libraries to the linker then though.

Jonas

We need this afaik for gtk2 too.

I was thinking about a simple global file with libnames and weights, with a possibility to override on the commandline.

Simple, generic, and configurable.

No, "gtk-config --libs" (or maybe "gtk2-config --libs" for gtk2?) tells you. In fact, there is also "sdl-config --libs", but of course it doesn't know anything about our system unit and main-troubles.

Or do you mean that gtk2 uses the same ugly hack of renaming the main procedure?

Jonas

On Fri, 3 Sep 2004 15:27:43 +0200 (CEST), Marco van de Voort wrote

This doesn't look very transparent to me (another place for configuration maintenance). What about optional parameter for $LINKLIB or something like that?

Tomas

04-09-03 15.27, skrev Marco van de Voort följande:

Macpas apps also has 2 'main', so the link order matters. I have hardcoded it so it always is correct.

Both Metrowerks and Think Pascal also has the ability to control link order, by drag and drop in a list...

Olle

True. By design though, more importantly, it is systemwide, and can be part of the release (no editing at all for "known" packages and updated as one single file.

What about optional parameter for $LINKLIB or something like that?

{$linklib }  can happen multiple times for the same lib in different units.

That is still manual, and will provoke a lot of msgs and questions about how this is done.

A gtk2 app probably easily will have 10+ libs.

What about adding a priority parameter: 100 default, 0 low, 200 high; if there are multiple linklib entries, the highest value is used.

The main problem is that it requires recompiling of the release in case of changes in order that conflicts somehow.

Instead of a separate file, we could add it as keyword to fpc.cfg, since fpc.cfg can be overriden.

#libpriority gtk2 100

The correct order and which libs you need can vary from OS to OS and maybe even from gtk2 release to release. There is no other way to really do it correctly than to rely on things like gtk-config.

Jonas

Setup could run gtk-config and stuff it in the files. Then at least we keep the compiler free from such patchwork, and center the "ugliness" in the weights file that can be operated on by the user, external tools etc.

Until someone upgrades his libraries and the next compile will be broken again. You have to work with makefiles to get around this. It has nothing to do with ugliness or patchwork on the compiler or language side imo, it's simply the way unix-type systems work and you have to deal with it one way or another.

The C-style building by default is simply more flexible in this regard, because the compiler is dumber and you can do whatever you want in the makefiles. If the compiler largely takes over make's job and you don't want to deviate from this, there is no way but to build in more make-like functionality in the compiler.

Jonas

This is no solution. I can use that, you can use that, 99% of our users can't.

The chances that the users get into problems with complex makefiles etc, is much harder than to have to tell them to run "fpcupdateweights" after a gtk version change.

It has nothing to do with ugliness or patchwork on the compiler or language side imo, it's simply the way unix-type systems work and you have to deal with it one way or another.

Yes, and the C-style is not the way for our users.

What is exactly wrong with having the weights somewhere? I never said anything about make in compiler, since it is not an issue of make, it is an issue of order of libraries.

That C (or better: GNU) solves this with configure/makefile fiddling and outside the compiler, doesn't mean we should either. We don't have e.g. a "configure" that is kept up to date outside of our projects for major platforms to fall back on.

It was all different if this was some obscure package we were dealing with, but this is gtk2 and SDL, and a large percentage of our *nix users will deal with it sooner or later.

I was not thinking of requiring the users to write makefiles (I agree we simply cannot do that). More that we call this stuff in the makefile, put the results in an include file using some compiler directives and store it in the ppu. However, that's also not a solution, since the user won't be recompiling the gtk units normally. Unless we put in the command itself, store that in the ppu-file and have the compiler always call it at compile-time.

I simply think the weights stuff will not solve it. It's handy if you know beforehand which libraries will be used and which will always have to be first, but who says that the linking order always has to be the same? Especially in case the linker supports multiple namespaces and one package needs symbol X from library A, and another one from library B.

I simply meant that our compiler does part of what make normally does (figuring out dependencies, compiling different files, ...), but it's not a full-fledged make replacement. And some kinds of things are easier to handle with make (you don't even need configure for that), since it can be told to call external programs to figure things out. Our compiler cannot do that (yet?)

Jonas

Yes, same reason why I moved it to the cfg file, and not have {$linklib xx weight} in source.

Unless we put in the command itself, store that in the ppu-file and have the compiler always call don't like this, because this is so gtk2 only. There is also SDL, and in

the future maybe a lot more "special" packages. I've had to rearrange libraries for static linking on *BSD too. (e.g. to get a fully static textmode IDE). Moreover what if gtk decides to add a linking parameter that breaks FPC ? (it's not all -l statements). It would break linking of the compiler.

How about crosslinking btw? I can transfer .so's and .a's to another machine, but can not run something like "gtk-config" there.

That's why it is in configfile, and not 100% baked in. (though executing gtk-config each time does)

Especially in case the linker supports multiple namespaces and one package needs symbol X from library A, and another one from library B.

There is always some directed graph in dependancies that can be translated into weights. But true, this kind of problems make having one weightfile a bit difference (since e.g. Mac OS X will probably be different).

Some autogeneration of options (appended to .cfg) might be needed.

One aspect I don't like from this, is that directives to support that creep back in the source. The weights system goes outside .ppu and source, and only affects the linker backend as it should.

{$execute gtk-config}  ? :-)

04-09-05 20.31, skrev Jonas Maebe följande:

I realized that the compiler is better than make is some respects.

When working with several targets (darwin and macos), fpc can see that the ppu file is from a different target and recompile, but make can't.

Olle

No, it's not per system, but per package/program. Suppose there are libraries A and B which both export symbol X. One program needs symbol X from library A, and another one from library B, but both need both libraries A and B for other symbols.

You then simply cannot assign a weight to A and B so that it works correctly in all cases.

Jonas

I always thought that fpc supports a.x and b.x for differenciating them, but never used it. Perhaps even a type definition in your program as

type
         Graphic = a.x;
         Incognite = b.x;

allows you use both without any problem.

P.S. From freepascal.com/advantage.html; Is this still true??

"Each unit has it's own identifiers In Pascal you never need to worry about polluting the namespace, like in C where an identifier needs to be unique accross the entire program. No, in Pascal each unit gets it's own namespace and that's very relaxed."

Las personas se dividen en tres grupos, los que saben contar y los que no. There are three groups of people, who can count, and who cannot.

That's for units, not for libraries.

Yes.

Jonas

This is still correct.

But it is NOT true for imported C library variables. The above statement is for pure pascal identifiers.

Michael.

04-09-06 15.06, skrev Eduardo Morras följande:

Yes it is still true. FPC generates unique names for the linker.

The problem mentioned in this thread occur when linking to software written in C.

Olle

On Mon, 06 Sep 2004 15:06:30 +0200, Eduardo Morras wrote

The problem is exactly that we have to link C libraries in this case where such namespaces aren't available.

Tomas

Sorry, for entering the discussion at this late stage. After reading all the follow-ups to Jonas message below, I understood that the culprit is still link ordering. If I understood something wrong, then please excuse my ignorance.

If not, It might help to add a link parameter (-k...) into the fpc command line. How about:

/usr/local/bin/ppcppc MyKillerApplication.pas -k-lsdl -oMyKillerApplication

This should result in an ld command in ppas.sh where the -lsdl statement is the very first parameter:

/usr/bin/ld -lsdl -L. -o MyKillerApplication `cat link.res`

system.o and allthelocalunits.o files come very late in link.res.

I am not able to check this, but it seems to me that the linker should pick the main entry point from the sdllib in this case. I think it shouldn´t be to hard for the users of fpc to add appropriate -k... parameters to the fpc command line.

Best regards

Rolf