Getting ready to port Cello (the Universal CL GUI) to XWindows, in the
guise first of Mac OS X.
But my poking around on various NGs suggests the only way to link an
OpenGL app under OS X (I have Panther and XCode, fwiw) is via some
(seemingly) OS X-specific "-framework OpenGL" and "-framework Glut"
build options in ProjectBuilder (and now XCode).
Unfortunately, this is Lisp, where libraries are loaded dynamically.
That would be DLLs on win32 and .SOs (I gather--this is all new to me)
on a *nix. Been searching my Mac HD as well as the NGs, and I do not see
anything looking like a library I can load.
I believe LW and MCL on the Mac support OpenGL, but maybe they link
their exes against the -frameworks?
Any ideas welcome.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
> Getting ready to port Cello (the Universal CL GUI) to XWindows, in the
> guise first of Mac OS X.
Yay! :-)
> But my poking around on various NGs suggests the only way to link an
> OpenGL app under OS X (I have Panther and XCode, fwiw) is via some
> (seemingly) OS X-specific "-framework OpenGL" and "-framework Glut"
> build options in ProjectBuilder (and now XCode).
>
> Unfortunately, this is Lisp, where libraries are loaded dynamically.
> That would be DLLs on win32 and .SOs (I gather--this is all new to me)
> on a *nix. Been searching my Mac HD as well as the NGs, and I do not see
> anything looking like a library I can load.
Check again :-). On Unix they are .so's, yes, but on OS X they are
called .dylib's.
If you pop into /System/Library/Frameworks/OpenGL.framework/ you'll
notice a Libraries folder. In there are the actual .dylib's for the
framework. These dylibs are all rolled into one at the root of the
Framework. So, /System/Library/Frameworks/OpenGL.framework/OpenGL is
the dylib you really need. There is also a Headers folder where all
the headers are located.
I created a quick skeleton GLUT program and linked it like this and it
works:
gcc test.cpp -lobjc -lstdc++
/System/Library/Frameworks/OpenGL.framework/OpenGL
/System/Library/Frameworks/GLUT.framework/GLUT
You may also wish to include
-I/System/Library/Frameworks/OpenGL.framework/Headers and the
equivalent for GLUT to put their headers in your include path.
Hope this helps. Good luck with everything.
Justin Dubs
From: james anderson
Subject: Re: Cello blues: Lisp+OpenGL+OS X?
Date:
Message-ID: <3FD44F31.8E8145F0@setf.de>
in mcl an application must link differently to libraries available as
frameworks only. [this was the context of our exchange some weeks back wrt imagemagick.]
the restriction does not apply to libraries which are available through the
standard "trap" interface as well. opengl is one of those.
check info-mcl and you will find progressive posts from alexander repenning
about various opengl-based tools.
Kenny Tilton wrote:
>
> Getting ready to port Cello (the Universal CL GUI) to XWindows, in the
> guise first of Mac OS X.
>
> But my poking around on various NGs suggests the only way to link an
> OpenGL app under OS X (I have Panther and XCode, fwiw) is via some
> (seemingly) OS X-specific "-framework OpenGL" and "-framework Glut"
> build options in ProjectBuilder (and now XCode).
>
> Unfortunately, this is Lisp, where libraries are loaded dynamically.
> That would be DLLs on win32 and .SOs (I gather--this is all new to me)
> on a *nix. Been searching my Mac HD as well as the NGs, and I do not see
> anything looking like a library I can load.
i recall that repenning's messages pointed readers at www.agentsheets.com
...
james anderson <··············@setf.de> writes:
> in mcl an application must link differently to libraries available as
> frameworks only. [this was the context of our exchange some weeks back wrt imagemagick.]
> the restriction does not apply to libraries which are available through the
> standard "trap" interface as well. opengl is one of those.
> check info-mcl and you will find progressive posts from alexander repenning
> about various opengl-based tools.
OpenGL is an area of interest to me. Graphics in general is what
brought me to Lisp. Anyway, I did a search in Finder and was rather
annoyed to find that the best looking documentation locally for
OpenGL was this:
file:///Developer/Documentation/Cocoa/Conceptual/OpenGL/OpenGL.html
That is the doc that you get if you install Dev Tools.
I also ran this command:
$ find / -name '*.dylib' 2>/dev/null | grep -i gl
/Applications/Mozilla.app/Contents/MacOS/components/libimglib2.dylib
/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libOpenGLContext.A.dylib
/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libOpenGLContext.dylib
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libOpenGLContext.A.dylib
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libOpenGLContext.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLSystem.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
/usr/local/lib/libglib-1.2.0.0.10.dylib
/usr/local/lib/libglib-1.2.0.dylib
/usr/local/lib/libglib.1.dylib
/usr/local/lib/libglib.dylib
/usr/X11R6/lib/libGL.1.2.dylib
/usr/X11R6/lib/libGL.1.dylib
/usr/X11R6/lib/libGL.dylib
/usr/X11R6/lib/libGLU.1.3.dylib
/usr/X11R6/lib/libGLU.1.dylib
/usr/X11R6/lib/libGLU.dylib
It looks to me like the standard C style OpenGL interfaces are
there. The X11R6 stuff may be because I installed the X11 server in
Panther. I have apps like GIMP that use it ;-). I also like to do
'ssh -X host' to get X11 forwarding through SSH which works nicely.
The /usr/local stuff is probably from Darwin Ports.
Mesa include files seem to be these (from the following find):
$ find / -name '*.h' 2>/dev/null | grep GL
...
/usr/X11R6/include/GL/gl.h
/usr/X11R6/include/GL/glext.h
/usr/X11R6/include/GL/glu.h
/usr/X11R6/include/GL/GLwDrawA.h
/usr/X11R6/include/GL/GLwDrawAP.h
/usr/X11R6/include/GL/GLwMDrawA.h
/usr/X11R6/include/GL/GLwMDrawAP.h
/usr/X11R6/include/GL/glx.h
/usr/X11R6/include/GL/glxext.h
/usr/X11R6/include/GL/glxint.h
/usr/X11R6/include/GL/glxmd.h
/usr/X11R6/include/GL/glxproto.h
/usr/X11R6/include/GL/glxtokens.h
/usr/X11R6/include/GL/osmesa.h
So if your OpenGL code works on Mesa under Linux, then it should port
to OS X. In C terms, there would probably be very little code
change. packages.debian.org is down at the moment. I seem to recall
there being a package for CMUCL for doing OpenGL, but I don't recall
the name of the package. I'm sure that rings a bell for someone
here. Does that package compile for SBCL or OpenMCL on OS X? Or is
that part of what has to be ported?
Granted my only actual OpenGL experience has been under Windows NT and
there was that stuff about getting a rendering context or whatever
setup. It's been a while for me. Never mind the fact that I bought
an expensive graphics card for my Linux box specificly for its OpenGL
abilities.
I wonder if there is a CLOS version of Open Inventor.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> It looks to me like the standard C style OpenGL interfaces are
> there.
Yes. I think the Finder "Find file..." dialog decided I was not really
looking for what I was looking for and decided not to show them to me.
> So if your OpenGL code works on Mesa under Linux, then it should port
> to OS X.
I am too old for Linux. :) I have win32 working from ACL and LW loading
DLLs, now I am trying for (I don't know) LW loading ???. Actually, I
intend to first try loading the .frameworks, and if that does not work
dash off a hot letter regarding "when on OS X, do as OS Xers do".
Hopefully any self-respecting CL implementation on OS X does The Right
Thing when asked to do a foreign lib load on something named "*.framework".
> I wonder if there is a CLOS version of Open Inventor.
I gave OpenRM a long look, thinking about using RMAux instead of Glut
for my window manager. I see on the OpenRM list that someone did
successfully port OpenRm to OS X on top of X11. I guess the nice thing
about Glut is that Apple is working on making that play nice with other
windows. But OpenRM of course brings along the added value of a scene
manager. I think in the end I decided I had Cello working on Freeglut so
I should get on with reaching more platforms instead of spending more
time fussing with window manager alternatives. OpenRM can be revisited
if Cello goes anywhere.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
james anderson wrote:
> in mcl an application must link differently to libraries available as
> frameworks only. [this was the context of our exchange some weeks back wrt imagemagick.]
Really? A classic case of "readiness" (as in I did not know enough at
the time even to hear what was being said.)
> the restriction does not apply to libraries which are available through the
> standard "trap" interface as well. opengl is one of those.
Oh. So I do not need libGL.dylib or libGLU.dylib? Cool.
> check info-mcl and you will find progressive posts from alexander repenning
> about various opengl-based tools.
Will do. Can't get thru on FTP just now to grab Alex's OpenGL contrib,
but it sounds promising.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Getting ready to port Cello (the Universal CL GUI) to XWindows, in the
> guise first of Mac OS X.
>
> But my poking around on various NGs suggests the only way to link an
> OpenGL app under OS X (I have Panther and XCode, fwiw) is via some
> (seemingly) OS X-specific "-framework OpenGL" and "-framework Glut"
> build options in ProjectBuilder (and now XCode).
>
> Unfortunately, this is Lisp, where libraries are loaded dynamically.
> That would be DLLs on win32 and .SOs (I gather--this is all new to me)
> on a *nix. Been searching my Mac HD as well as the NGs, and I do not see
> anything looking like a library I can load.
>
> I believe LW and MCL on the Mac support OpenGL, but maybe they link
> their exes against the -frameworks?
Shared libraries are either files with a ".dylib" extension, or
frameworks. Framework libraries have not distinguishing extension, but
instead are found in special paths; for example,
/System/Library/Frameworks/GLUT.framework/GLUT
is the GLUT shared library.
A good way to see how to open shared libaries on OSX from Lisp is to
look at examples in the OpenMCL sources that do it. For example, the
opengl-ffi.lisp example does this:
(open-shared-library "GLUT.framework/GLUT")
Assuming you're not using OpenMCL for your port, you can still walk the
code and use grep a bit to see what OPEN-SHARED-LIBRARY actually does,
since the sources of OpenMCL are available. The definition of
OPEN-SHARED-LIBRARY is
(defun open-shared-library (name)
(let* ((link-map (with-cstrs ((name name))
(ff-call
(%kernel-import arch::kernel-import-GetSharedLibrary)
:address name
:unsigned-fullword *dlopen-flags*
:address))))
(if (%null-ptr-p link-map)
(error "Error opening shared library ~s: ~a" name (dlerror))
(prog1 (let* ((lib (shlib-from-map-entry link-map)))
(incf (shlib.opencount lib))
lib)
(%walk-shared-libraries
#'(lambda (map)
(unless (shared-library-at
(%int-to-ptr (pref map :link_map.l_addr)))
(let* ((new (shlib-from-map-entry map)))
(%dlopen-shlib new)))))))))
...and then of course you want to grep around and find the definition of
SHLIB-FROM-MAP-ENTRY and so on.