Hi all.

I was trying to link with a C library, and everything went well till one function popped up that didn't wan't to work. Till I investigated the source library code, and found that it was in fact a macro that referenced fields from a struct.

The only solution I found, was to write a few C functions that call the macro, then I link to that C proggie. Hardly elegant... Is there a another solution to this?

Thanks

John

No. When we translate C library header files, we rewrite the macros always as pascal functions. The h2pas conversion tool takes a shot at this, but the translation always needs to be hand-tweaked.

Michael.

Hi,
I've got two questions, I'm working with the glut libraries, gl and glut, but I can't work with the library glu, where could I get it from? And I'd like to know which version the implementation of the glut Libraries is.

Holger

Hello Michael.

I wanted to avoid changing the original header files, because this seemed problematic: if new versions of the header files appear, it would be necessary to reapply the h2pas or similar step, wouldn't it?

Writing a proper C interface avoids this problem, but means it's necessary to link with an extra .o file. I wonder if it would be possible to combine the C-generated .o and the Pascal generated .o into one lib.

Thanks,
John

We don't modify the headers. We translate what is possible, and rewrite the rest as pascal functions. We do the same as you do, only we do it in pascal, you do it in C :-)

Writing a proper C interface avoids this problem, but means it's necessary to link with an extra .o file. I wonder if it would be possible to combine the C-generated .o and the Pascal generated .o into one lib.

You need to recompile the C interface anyway.
But yes, you can put this in one lib.

Michael.

We don't modify the headers. We translate what is possible, and rewrite the rest as pascal functions. We do the same as you do, only we do it in pascal, you do it in C :-)

Ahhh... That hurts... ;-)

Ok I understood you translated the entire header. Guess both approaches are valid then.

Thanks.

John

Hi, I've got two questions, I'm working with the glut libraries, gl and glut, but I can't work with the library glu, where could I get it from?

normally glu is installed per default?

And I'd like to know which version the implementation of the glut Libraries is.

based on MESA 3.0, I think it's GLU 1.1

I'll try to get some much more recent OpenGL units for Delphi working in FPC within the next few days, so stay tuned...

- Sebastian

Hi!

> I've got two questions, I'm working with the glut libraries, gl and > glut, but I can't work with the library glu, where could I get it from? normally glu is installed per default?

I think it is a fault in the FreePascal distribution, because it doesn't deliver the glu.{o,ppu} files. I always copied them from earlier FPC versions. Could you please investigate why it is not included and fix this for all upcoming releases?

Thanks
Hansi

I think it is a fault in the FreePascal distribution, because it doesn't deliver the glu.{o,ppu} files. I always copied them from earlier FPC versions. Could you please investigate why it is not included and fix this for all upcoming releases?

The makefile is broken. Peter?

- Sebastian

Hi,
I've got them now from the FTP Server. And compiled them. They are working now.

What's the difference between gl, (glut, glut) and gl_sl, (glut_sl, glu_sl)?

Holger

sl = statically linked

The default (dynamic) units try to load the OpenGL libraries at runtime; then they get the addresses for each function manually. The static units directly access the external symbols.

Note that this variant won't exist anymore in the next version of the units.

- Sebastian

----- Original Message -----