February 2004 - cells-devel - mailman3.common-lisp.net

[cells-devel] PortaCello 1.0: MagickFlipImage and others not available on Linux...
by Frank Goenninger 25 Feb '04

25 Feb '04

Hi all: Hmmmmm - this is a strange one again: I cannot find a source for ImageMagick (the library) where the functions MagickFlipImage, MagickGetImageWidth, and MagickGetImageHeight (and possibly more) functions are implemented. In the sources I have of ImageMagick (version 5.5.7) there are no such functions. I am using the C shared library of ImageMagick. There is also a C++ shared lib... Anyone using that? Kenny, which version do you use? And I thought I'd see something on the screen after solving the shared lib loading problem... ;-)) Thx for feedback. Regards, Frank

2 2

[cells-devel] [Fwd: Re: [spr28621] AllegroCL6.2 Trial user attempt to load his C++ shared library fails]
by Frank Goenninger 24 Feb '04

24 Feb '04

Solved! Great support from Franz! Simple cause - simple fix in the current state of Cello. But with ugly consequences for a production environment. Summary: ACL identifies foreign files by their endings. A ".so" file is recognized as a shared library - but most shared libs on Linux have a version info behind the ".so". Example: "libc.so.6" ... As these are different from file to file the recognition fails. Unfortunately it is not helpful to make a symbolic link that is named just "libc.so" (to stay with the above example). See below for details. Regards, Frank -----Forwarded Message----- From: Lois Wolf <lwolf(a)franz.com> To: frank_goenninger(a)t-online.de Cc: support(a)franz.com, frank_goenninger(a)goenninger.com, sales(a)franz.com Subject: Re: [spr28621] AllegroCL6.2 Trial user attempt to load his C++ shared library fails Date: Tue, 24 Feb 2004 13:37:44 -0800 Frank Goenninger: In Allegro CL 6.2 only files for which the file extension is an element of the list which is the value of the unexported symbol excl::*load-foreign-types* are recognized as foreign files. (This behavior is likely to be improved in Allegro CL 7.0) To make your file libftglint.so.1 recognizable to Allegro CL 6.2 as a foreign file, you can push "1" onto the value of excl::*load-foreign-types*, change the name of the file, or create a symbolic link with extension .so and load that. Please send any further email related to this problem report to support(a)franz.com with the identifier spr28621 in the subject line. Thanks, Lois Wolf Franz Inc., http://www.franz.com/ lwolf(a)franz.com 555 12th St, Suite 1450 (510) 452-2000; Fax: (510) 452-0182 Oakland, CA 94607

1 0

[cells-devel] Re: Problem Report: frgo/001/a0100: Cannot load C++ shared library
by Frank Goenninger 24 Feb '04

24 Feb '04

Dear Support Team: Here is some additional info about observations I made when trying to fix the problem outlined below: 1. In some cases ACL fails to load shared libs when the path points to a symbolic link instead of a real file. 2. The error is related to the file identification behavior of `load': * In case of correctly identifying the file as a foreign file the message appearing is "; foreign loading ..." * In case of not correctly identifying the file as a foreign file the message is (consistently) "; loading ..." So I wanted to direct this into finding out how `load' identifies foreign files as such. Unfortunately, I wasn't able to find a lower level call that "really loads a foreign file" (assuming load is just the top layer and the interface to underlying machinery). Any hints are appreciated. Thanks again. Best regards, Frank Goenninger On Tue, 2004-02-24 at 00:01, Frank Goenninger wrote: > Dear Support Team @ Franz: > > I am currently struggling to load a shared library using `load'. > > I would appreciate your help in sorting this out. Thank you very much > in advance! > > I. DRIBBLE FILE > > See attached dribble-bug file for a session transcript and system infos. > > II. PROBLEM DESCRIPTION > > Product: ACL 6.2 Trial > Plattform: Debian/Linux, Kernel 2.4.20, glibc3.3 > > I have a "homebrew" shared library that contains several C++ object > files. When I try to load that shared library I consistently get the > following error: > > ; Loading /home/frgo/projects/cello/ftgl-int/libftglint.so.1 > Error: Attempt to take the value of the unbound variable > ^?ELF^A^A^A^A^A^A .... > [condition type: UNBOUND-VARIABLE] > > A first interpretation on my side was that the generated shared > library is somehow damaged in the format and `load' is unable to > determine the right way to actually load it. So I wrote a short > C program to test if I can load it using plain C methods. > > This succeeds - the functions used are dlopen, dlsym, and dlclose. > > See section III. Example/Test of this email for the actual source > code. > > A second interpretation would be that the C++ shared library loads > into different memory regions than a normal C shared library - > thereby destroying memory regions occupied by the AllegroCL image. > But this is beyond my testing possibilities... > > I checked carefully all documentation for AllegroCL 6.2 on your > web site and also did some googling for relevant info - no luck... > > III. Example/Test Source Code > > Attachment "Makefile": a generated Makefile, to be called by `make'. > Attachments "FTGLFromC.cpp", "main.cpp": source code files. > Attachment "libftglint.so.1": The shared lib built from FTGLFromC.cpp > and a futher, precompiled static library. > Attachment "ftgl.lisp": The Lisp source file containing the code to > load the shared libs. > > Note: Loading plain C shared libs works as expected. > > The Lisp source uses UFFI as a layer in between AllegroCL's own > foreign function interface. For AllegroCL the call to > uffi:load-foreign-library simply translates into a call to > load. > > Of course I am ready to answer questions. You may reach me by phone: > > +49 7123 932355 > > or by email. Just reply to this email. > > THANKS AGAIN! > > Best regards, > > Frank Gönninger > > -- > Frank Gönninger, DG1SBG > Bempflingen, Germany > >

1 0

[cells-devel] loading under Linux
by Kenny Tilton 24 Feb '04

24 Feb '04

In case you missed it on cll today: Kenny Tilton <ktilton(a)nyc.rr.com> writes: >>>>>>I am doing the latter because one porter is having trouble so far >>>>>>loading on Linux the FTGL lib I use for fonts under win32. And anyway, >>>>>>it would be nice to have these libraries as clearly delineated >>>>>>components one can use or not without giving up the rest of Cello. >> >>>> what's his problem? FTGL works here (gentoo GNU/Linux, not sure if i >>>> haven't compiled it myself though). > >> >> Are you using FTGL from Lisp? Without C glue? nope. i misunderstood "loading on Linux the FTGL lib". sorry. >> What I did on win32 was write a few lines of C glue to get at the C++ >> FTGL classes, then rebuild the FTGL dll with that code. I believe the >> porter created a .SO for the C glue, linking that with a virgin FTGL >> static lib. AllegroCL on Linux then screams about something being >> unreadable when he tries to load the glue SO. Look for a recent query >> here from Frank G. He is able to load SOs as a rule, but the ones he >> builds have an issue, so it is probably some obscure linker >> incantation or compiler directive that is needed. Ideas welcome. i'm doing something similar but with cmucl, i wanna use my favorite media library from lisp, but it has ugly API so i'm writing some helper functions to hide ugliness from lisp. i can use the library from C without much thinking, but when loading it into lisp i have to say: (load-foreign '("artm-wrap.o" "libmedia1.a" "libmedia2.a") :libraries '("-lc" "-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/" "-lgcc" "-lz")) i guess the libmedia uses some gcc-specific features on linux which require linking with gcc... i'm not sure how this would have looked in allegrocl, but the issue might be the same, no? -- gr{oe|ee}t{en|ings} artm

2 4

[cells-devel] PortaGlut 1.0
by Kenny Tilton 24 Feb '04

24 Feb '04

Raistlin, Sorry, I tried BCCing cells-devel when I posted the errata below to comp.lang.lisp, but did not notice that they never appeared. Raistlin Magere wrote: > Ok I have played with portaglut only a few minutes so nothing too > insightfull: > I load the program by running first "glbind.lpr" [no errors here] and > then "opengl-ffi.lpr" which returns the following error > > Error: (SETF NIL) does not have a function definition > [condition type: SIMPLE-ERROR] I have no idea what is going on with that. See errata for my fulminations againt the project manager, which is dandy but can be a total PITA sometimes. > > > the options are to skip loading uffi.lpr (which was already loaded by > glbind) or to skip loading opengl-ffi, aborting the loading of > uffi.lpr seems to solve the problem. Sh*t, I kept telling myself to delete glbind.lpr. That was an old name for it. Just use opengl-ffi.lpr. I am totally sorry for wasting your time by neglecting to delete that file. > > In fact deleting from opengl-ffi the line > :projects (list (make-instance 'project-module :name > "\\dvx\\uffi\\uffi")) > allows the loading of the two projects in succession without any > problem, by the way I need to run the two project as opengl-ffi > although requiring glbind doesn't automatically load it. > > I then run (ogb::lesson-14) and get the following error > > Error: Attempt to call #("glClearDepth" 1669795401 0 2 1669795401) for > which the definition has not yet been (or is no longer) loaded. > [condition type: SIMPLE-ERROR] That was in the errata. I need to add a wrapper for uffi::load-library which checks that the library exists. uffi does not. Find the hard-coded loads of opengl32 and glu32 and change to match your configuration. > > The program does manage to create a new window titled "NeHe's OpenGL > Framework" however I only see the outline of it and nothing else. > > By the way I got an error similar to the one above when I tried to > load a dll I had made for test purpose to learn to use uffi or > acl-ffi, the loading of the dll went fine and lisp said library loaded > however when trying to call the function I would get the same error (I > think even the same numbers) but with the name of the function I had > tried to call. I then gave up on ffi and uffi - though I still need to > use some c code. Maybe this will help me out also with my work. Well, it might be different, but I can help with that, too. The first thing to do is what I will do to fix my stuff: (let ((dll-path "whatever")) (assert (probe-file dll-path)) (uffi:load-library dll-path)) If that works, well, what C compiler are you using? Using VC++, I have to do two things: wrap the C functions in extern "C" {} declarations /and/ list each function name in a .DEF file included in the source for the VC++ project. I /think/ naming the C file is an alternative to wrapping the function in the extern form. The FTGLFromC.cpp and the def file I sent illustrate the above. Sorry again I botched sending the errata (below). kenny Kenny Tilton wrote: > OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): > > http://www.tilton-technology.com/cellophane.html > Just installed from ZIP. Errata: 1. In dvx/lib there is a freeglut.zip from which freeglut.dll should be extracted. Won't happen again. 2. Look for load of freeglut.dll from hard-coded "D:/dvx/lib". 3. Also look for hard-coded loads of opengl32 and glu32 from "/winnt". That's "/windows" on other wins, lord knows what on other oses. The bad news here is that uffi:load-library seems not to mind at all if it is asked to load a non-existent library, so the first sign of trouble is a runtime erorr something like "glClearColor? what the hell is that?" 4. ACL users: because the handling of the project files is such a phenomenal PITA, I get "opengl-bindings" package not found because after I change the defpackage inside the LPR (it's just source) to: (defpackage :opengl-bindings...) ACL changes it back to common-graphics whenever it feels like it. :) I would tell you the fix if I knew one, but in the past I just turn a few hundred monkeys trying things at random until it works, and then I never know which monkey fixed it nor certainly what they did to fix it. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

RE: [cells-devel] PortaGlut 1.0
by Raistlin Magere 24 Feb '04

24 Feb '04

Ok I have played with portaglut only a few minutes so nothing too insightfull: I load the program by running first "glbind.lpr" [no errors here] and then "opengl-ffi.lpr" which returns the following error Error: (SETF NIL) does not have a function definition [condition type: SIMPLE-ERROR] the options are to skip loading uffi.lpr (which was already loaded by glbind) or to skip loading opengl-ffi, aborting the loading of uffi.lpr seems to solve the problem. In fact deleting from opengl-ffi the line :projects (list (make-instance 'project-module :name "\\dvx\\uffi\\uffi")) allows the loading of the two projects in succession without any problem, by the way I need to run the two project as opengl-ffi although requiring glbind doesn't automatically load it. I then run (ogb::lesson-14) and get the following error Error: Attempt to call #("glClearDepth" 1669795401 0 2 1669795401) for which the definition has not yet been (or is no longer) loaded. [condition type: SIMPLE-ERROR] The program does manage to create a new window titled "NeHe's OpenGL Framework" however I only see the outline of it and nothing else. By the way I got an error similar to the one above when I tried to load a dll I had made for test purpose to learn to use uffi or acl-ffi, the loading of the dll went fine and lisp said library loaded however when trying to call the function I would get the same error (I think even the same numbers) but with the name of the function I had tried to call. I then gave up on ffi and uffi - though I still need to use some c code. Maybe this will help me out also with my work. Raistlin _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

[cells-devel] CelloGlut AOK
by Kenny Tilton 24 Feb '04

24 Feb '04

Man, this was easy. I now have several demos including the wildest one running under what I call CelloGlut, which just adds Cells and the bulk of the Cello gui. No new libraries such as FTGL or ImageMagick. The downside is that only the two stroke fonts are available (one mono-spaced, one variable) and they look like hell, but this is just to have an intermediate porting step (not that some folks would not be able to make use of CelloGlut) and I believe a little opengl work would fix the stroke fonts up a bit. A little cosmetic work tomorrow and I can make another release. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] portaglut 1.0
by Kenny Tilton 24 Feb '04

24 Feb '04

A mail message to y'all bounced on a bad address, and the bounce won't show me the original. But I did post a similar to cll: OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): http://www.tilton-technology.com/cellophane.html Under "Early Cello Screen Shots", first paragraph, Portaglut (in the form of dvx.ZIP, lies behind the "bindings" link. I just built and ran via ACL LPRs and ACL using ASDF. See "build.lisp" now at top level in new DVX directory, replacing DEV which was bad for Linux/Unix. Build.lisp was in the cello directory. The test function, as you will see in build.lisp, is (ogb::lesson-14). The string "NeHe etc " swigns around in 3D. Hit esacpe to quit. This will be quite a Hello,World. It involves successfully building bindings to opengl as well as FreeGlut, and it shows callbacks Lisp->C->Lisp work (and loading shared libs). Note that this does not involve Cells, any Cello gui, FTGL, or ImageMagick. It also has hard-coded DLL locations and more out the wazoo. Seek and destroy. btw, lesson-14 used to have code in there that used the glut bitmap fonts as well as the glut stroke fonts now in there. those calls brought down freeglut and the Lisp ide, so I yanked them. caveat: Originally developed/tested on XP/ACL62, then ported to NT/ACL501 to resolve a problem there. I have not yet swapped this back to my ACL62/XP setup to make sure it still works there, but I will tonight sometime. caveat: To make UFFI work under ACL501 I snuck a conditionalization onto one place where the ACL62-only :strings-convert option was used. invitation: questions, comments, fixes for new environments. however: regrettably, I myself won't have time to come up with fixes for new environments. peace, love, and the z-axis, kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] Re: ANNC: Lisp FFI tools with OpenGL+Glut samples
by Kenny Tilton 24 Feb '04

24 Feb '04

Kenny Tilton wrote: > OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): > > http://www.tilton-technology.com/cellophane.html > Just installed from ZIP. Errata: 1. In dvx/lib there is a freeglut.zip from which freeglut.dll should be extracted. Won't happen again. 2. Look for load of freeglut.dll from hard-coded "D:/dvx/lib". 3. Also look for hard-coded loads of opengl32 and glu32 from "/winnt". That's "/windows" on other wins, lord knows what on other oses. The bad news here is that uffi:load-library seems not to mind at all if it is asked to load a non-existent library, so the first sign of trouble is a runtime erorr something like "glClearColor? what the hell is that?" 4. ACL users: because the handling of the project files is such a phenomenal PITA, I get "opengl-bindings" package not found because after I change the defpackage inside the LPR (it's just source) to: (defpackage :opengl-bindings...) ACL changes it back to common-graphics whenever it feels like it. :) I would tell you the fix if I knew one, but in the past I just turn a few hundred monkeys trying things at random until it works, and then I never know which monkey fixed it nor certainly what they did to fix it. kenny

1 0

[cells-devel] PortaGlut 1.0
by Kenny Tilton 24 Feb '04

24 Feb '04

A mail message to y'all bounced on a bad address, and the bounce won't show me the original. But I did post a similar to cll: OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): http://www.tilton-technology.com/cellophane.html Under "Early Cello Screen Shots", first paragraph, Portaglut (in the form of dvx.ZIP, lies behind the "bindings" link. I just built and ran via ACL LPRs and ACL using ASDF. See "build.lisp" now at top level in new DVX directory, replacing DEV which was bad for Linux/Unix. Build.lisp was in the cello directory. The test function, as you will see in build.lisp, is (ogb::lesson-14). The string "NeHe etc " swigns around in 3D. Hit esacpe to quit. This will be quite a Hello,World. It involves successfully building bindings to opengl as well as FreeGlut, and it shows callbacks Lisp->C->Lisp work (and loading shared libs). Note that this does not involve Cells, any Cello gui, FTGL, or ImageMagick. It also has hard-coded DLL locations and more out the wazoo. Seek and destroy. btw, lesson-14 used to have code in there that used the glut bitmap fonts as well as the glut stroke fonts now in there. those calls brought down freeglut and the Lisp ide, so I yanked them. caveat: Originally developed/tested on XP/ACL62, then ported to NT/ACL501 to resolve a problem there. I have not yet swapped this back to my ACL62/XP setup to make sure it still works there, but I will tonight sometime. caveat: To make UFFI work under ACL501 I snuck a conditionalization onto one place where the ACL62-only :strings-convert option was used. invitation: questions, comments, fixes for new environments. however: regrettably, I myself won't have time to come up with fixes for new environments. peace, love, and the z-axis, kenny

1 0