Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OpenGL in Fortran
405 views
Skip to first unread message
Dick Holmes
Feb 5, 2016, 5:32:03 PM2/5/16
to
I am attempting to use OpenGL in Fortran. I am using the F03GL package
with gfortran (4.9 and 5.3) and FreeGLUT on Windows 10. A simple program
compiles with no problems (after cleaning up the Makefile), but it
segfaults during execution. The segfault trace is the same for both
compiler versions once the program gets into the innards of OpenGL.
When I try to trace the problem using gdb, the program runs correctly
(as far as I can tell) during the phase where I'm passing data to OpenGL
to set up a rendering. The begin and vertex calls leave the stack in
good shape. When I issue the glEnd subroutine call, the stack gets
trashed and the program fails when the OpenGL code tries to return.
I suspect that there is an incompatibility between the calling sequences
generated by the gfortran compiler and the calling sequences built in to
the opengl32.dll library supplied by Microsoft. I have tried to change
the calling sequence but it doesn't seem to make any difference (the
program fails at the same addresses). It is possible (likely?) that I'm
not really changing the calling sequence. So,
-- has anyone else tried this combination successfully (the F03GL folks
seem to have done that, but I can't duplicate their success)?
-- how should I be changing the generated calling sequence, for example
from stdcall to cdecl (or whatever may be appropriate)?
Suggections gratefully accepted.
Dick Holmes
with gfortran (4.9 and 5.3) and FreeGLUT on Windows 10. A simple program
compiles with no problems (after cleaning up the Makefile), but it
segfaults during execution. The segfault trace is the same for both
compiler versions once the program gets into the innards of OpenGL.
When I try to trace the problem using gdb, the program runs correctly
(as far as I can tell) during the phase where I'm passing data to OpenGL
to set up a rendering. The begin and vertex calls leave the stack in
good shape. When I issue the glEnd subroutine call, the stack gets
trashed and the program fails when the OpenGL code tries to return.
I suspect that there is an incompatibility between the calling sequences
generated by the gfortran compiler and the calling sequences built in to
the opengl32.dll library supplied by Microsoft. I have tried to change
the calling sequence but it doesn't seem to make any difference (the
program fails at the same addresses). It is possible (likely?) that I'm
not really changing the calling sequence. So,
-- has anyone else tried this combination successfully (the F03GL folks
seem to have done that, but I can't duplicate their success)?
-- how should I be changing the generated calling sequence, for example
from stdcall to cdecl (or whatever may be appropriate)?
Suggections gratefully accepted.
Dick Holmes
James Van Buskirk
Feb 5, 2016, 10:34:48 PM2/5/16
to
"Dick Holmes" wrote in message
news:MPG.311ec29a2...@news.supernews.com...
I used to have OpenGL interface modules for gfortran on my
website before it was destroyed by vandals and thieves. opengl32.dll
definitely wants you to declare everything as STDCALL. One way to
finesse that issue is to try to make everything work in 64-bit mode.
If you use FreeGLUT you will have to get a 64-bit FreeGLUT package.
Looks like Nvidia has a 64-bit GLUT you can install.
GLUT is kind of crappy anyhow because you can't render to the
printer or to a file with it. But opening up an OpenGL window
from scratch is a daunting task if you can't find example code to
copy. There is some at NeHe's web site.
news:MPG.311ec29a2...@news.supernews.com...
website before it was destroyed by vandals and thieves. opengl32.dll
definitely wants you to declare everything as STDCALL. One way to
finesse that issue is to try to make everything work in 64-bit mode.
If you use FreeGLUT you will have to get a 64-bit FreeGLUT package.
Looks like Nvidia has a 64-bit GLUT you can install.
GLUT is kind of crappy anyhow because you can't render to the
printer or to a file with it. But opening up an OpenGL window
from scratch is a daunting task if you can't find example code to
copy. There is some at NeHe's web site.
town...@astro.wisc.edu
Feb 21, 2016, 11:11:24 AM2/21/16
to
Let me know if you are interested.
cheers,
Rich
town...@astro.wisc.edu
Feb 21, 2016, 11:14:36 AM2/21/16
to
cheers,
Rich
James Van Buskirk
Feb 21, 2016, 11:57:07 AM2/21/16
to
wrote in message
news:c81a5a4e-bf94-40ae...@googlegroups.com...
I converted almost all the extensions to OpenGL once (converting
arguments of type void** requires review on a case by case basis)
and wrote up sort of a Fortran GLEW package, but I haven't
looked at any OpenGL stuff for a while.
news:c81a5a4e-bf94-40ae...@googlegroups.com...
> Apologies, the interface is to GLFW, not SDL. But it works well.
GLFW doesn't seem to be able to render to a file or the printer.
I converted almost all the extensions to OpenGL once (converting
arguments of type void** requires review on a case by case basis)
and wrote up sort of a Fortran GLEW package, but I haven't
looked at any OpenGL stuff for a while.
Dick Holmes
Feb 22, 2016, 5:35:45 PM2/22/16
to
In article <c81a5a4e-bf94-40ae...@googlegroups.com>,
town...@astro.wisc.edu says...
around the interface problem (interfacing between Fortran, GLUT and
OpenGL). I discovered GLFW and have been attempting to work with that
model for the last few days, but I'm having the same kinds of problems.
With GLFW3, I instrumented the source and discovered that I am passing
the same value for a window handle to several different GLFW routines,
but when I attempt to swap buffers, the window parameter value is
different once it gets into the GLFW code even though I'm calling with
the same handle variable. The defined interfaces are the same for all
the functions that pass a window handle. The result of the bad (?)
handle value is a seg fault.
The other problem I encountered is some kind of chaos with regard to the
stack. When I call a subroutine to render my image, the GL calls seem to
work fine until I try to exit the subroutine. At that point the stack is
corrupted and I end up in a graphics driver (Intel 5500 latest driver).
I don't understand what got me to that driver, but that may be a side
effect of the corrupted stack.
I'm on Windows 10 using gfortran 5.3 and have been forcing the stdcall
procedure calling sequence using the command line option (-mrtd) and the
!GCC$ attributes.
I'd be delighted to have a look at your GLFW code!
____________
Dick
town...@astro.wisc.edu says...
>
> On Sunday, February 21, 2016 at 10:11:24 AM UTC-6, town...@astro.wisc.edu wrote:
> > On Friday, February 5, 2016 at 9:34:48 PM UTC-6, James Van Buskirk wrote:
> > > "Dick Holmes" wrote in message
> > > news:MPG.311ec29a2...@news.supernews.com...
> > >
> > > > I am attempting to use OpenGL in Fortran. I am using the F03GL package
> > > > with gfortran (4.9 and 5.3) and FreeGLUT on Windows 10. A simple program
> > > > compiles with no problems (after cleaning up the Makefile), but it
> > > > segfaults during execution. The segfault trace is the same for both
> > > > compiler versions once the program gets into the innards of OpenGL.
> > >
[snip]
> On Sunday, February 21, 2016 at 10:11:24 AM UTC-6, town...@astro.wisc.edu wrote:
> > On Friday, February 5, 2016 at 9:34:48 PM UTC-6, James Van Buskirk wrote:
> > > "Dick Holmes" wrote in message
> > > news:MPG.311ec29a2...@news.supernews.com...
> > >
> > > > I am attempting to use OpenGL in Fortran. I am using the F03GL package
> > > > with gfortran (4.9 and 5.3) and FreeGLUT on Windows 10. A simple program
> > > > compiles with no problems (after cleaning up the Makefile), but it
> > > > segfaults during execution. The segfault trace is the same for both
> > > > compiler versions once the program gets into the innards of OpenGL.
> > >
> > >
> > > I used to have OpenGL interface modules for gfortran on my
> > > website before it was destroyed by vandals and thieves. opengl32.dll
> > > definitely wants you to declare everything as STDCALL. One way to
> > > finesse that issue is to try to make everything work in 64-bit mode.
> > > If you use FreeGLUT you will have to get a 64-bit FreeGLUT package.
> > > Looks like Nvidia has a 64-bit GLUT you can install.
> > >
> > > GLUT is kind of crappy anyhow because you can't render to the
> > > printer or to a file with it. But opening up an OpenGL window
> > > from scratch is a daunting task if you can't find example code to
> > > copy. There is some at NeHe's web site.
> >
> > I created a Fortran interface to SDL, that I'd be happy to share.
> > I also have a partial set of interfaces for OpenGL >= 3, but that
would require bit more work for me to make available.
> >
> > Let me know if you are interested.
> >
> > cheers,
> >
Actually, I gave up on the GLUT family since I couldn't seem to get
> > > I used to have OpenGL interface modules for gfortran on my
> > > website before it was destroyed by vandals and thieves. opengl32.dll
> > > definitely wants you to declare everything as STDCALL. One way to
> > > finesse that issue is to try to make everything work in 64-bit mode.
> > > If you use FreeGLUT you will have to get a 64-bit FreeGLUT package.
> > > Looks like Nvidia has a 64-bit GLUT you can install.
> > >
> > > GLUT is kind of crappy anyhow because you can't render to the
> > > printer or to a file with it. But opening up an OpenGL window
> > > from scratch is a daunting task if you can't find example code to
> > > copy. There is some at NeHe's web site.
> >
> > I created a Fortran interface to SDL, that I'd be happy to share.
> > I also have a partial set of interfaces for OpenGL >= 3, but that
would require bit more work for me to make available.
> >
> > Let me know if you are interested.
> >
> > cheers,
> >
around the interface problem (interfacing between Fortran, GLUT and
OpenGL). I discovered GLFW and have been attempting to work with that
model for the last few days, but I'm having the same kinds of problems.
With GLFW3, I instrumented the source and discovered that I am passing
the same value for a window handle to several different GLFW routines,
but when I attempt to swap buffers, the window parameter value is
different once it gets into the GLFW code even though I'm calling with
the same handle variable. The defined interfaces are the same for all
the functions that pass a window handle. The result of the bad (?)
handle value is a seg fault.
The other problem I encountered is some kind of chaos with regard to the
stack. When I call a subroutine to render my image, the GL calls seem to
work fine until I try to exit the subroutine. At that point the stack is
corrupted and I end up in a graphics driver (Intel 5500 latest driver).
I don't understand what got me to that driver, but that may be a side
effect of the corrupted stack.
I'm on Windows 10 using gfortran 5.3 and have been forcing the stdcall
procedure calling sequence using the command line option (-mrtd) and the
!GCC$ attributes.
I'd be delighted to have a look at your GLFW code!
____________
Dick
James Van Buskirk
Feb 22, 2016, 5:59:15 PM2/22/16
to
"Dick Holmes" wrote in message
news:MPG.31352d121...@news.supernews.com...
> I'm on Windows 10 using gfortran 5.3 and have been forcing the stdcall
> procedure calling sequence using the command line option (-mrtd) and the
> !GCC$ attributes.
along with
!GCC$ ATTRIBUTES STDCALL :: ProcedureName
Or better, test your code first under 64 bits where STDCALL is simply
not an issue so that you can tell whether your problems are due to
an unbalanced stack arising from inconsistent calling conventions
in 32 bit mode or something else.
Dick Holmes
Feb 27, 2016, 12:05:41 PM2/27/16
to
In article <nag3md$prc$1...@dont-email.me>, not_...@comcast.net says...
Rich and James: Thanks to your suggestions I fixed the problem and I can
now use GLFW to access OpenGL.
Thanks for your help
__
Dick
now use GLFW to access OpenGL.
Thanks for your help
__
Dick
0 new messages