From: Christopher W. <cr...@ms...> - 2004-07-28 21:29:43
|
When running a CRUT program, are the crappfaker's supposed to be capturing system-specific OGL functions? I've come to a hard wall where the only way to pass it is to disable the 'faking' in app_faker. The problem seems to be that when the render spu is creating the default window, it makes a context to go with it, but instead of calling the system's functions, it calls the functions in opengl_stub. I'm wondering if this was intentional? Knowing if it was or not will help me decide where to go with this. =) There is another problem, but it's more Darwin oriented. I've spent a good bit of time trying to figure out how to get a handle to GLUT's window for CRUT (in crutserver), but with (OSX's) GLUT being written in Obj-C, things aren't going smoothly. Would anyone know anything about how to go about doing this? While I'm on the topic of Darwin, last week I made a patch to update to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k is too big of a file to send to the mailing list. =\ I'll most likely flesh-out and send an updated patch later this week. -Chris Waters |
From: Mike H. <mho...@gr...> - 2004-07-28 21:54:11
|
I'll try to take a stab at this since I was probably the last person to touch the CRUT stuff. Christopher Waters wrote: > When running a CRUT program, are the crappfaker's supposed to be > capturing system-specific OGL functions? I've come to a hard wall where > the only way to pass it is to disable the 'faking' in app_faker. The > problem seems to be that when the render spu is creating the default > window, it makes a context to go with it, but instead of calling the > system's functions, it calls the functions in opengl_stub. I'm > wondering if this was intentional? Knowing if it was or not will help > me decide where to go with this. =) CRUT applications create a windows and a context using Chromium functions, not standard system functions. This is done so that we can have full control over the context/window to handle events. Nothing is really done until the renderSPU come up and really does the context and window creation. The CRUT implementation in general is not as clean as it can or should be since we have not had many people work with it, on it, or who rely on it. > > There is another problem, but it's more Darwin oriented. I've spent a > good bit of time trying to figure out how to get a handle to GLUT's > window for CRUT (in crutserver), but with (OSX's) GLUT being written in > Obj-C, things aren't going smoothly. Would anyone know anything about > how to go about doing this? > We have a similar issue in Windows. In the windows case, there is no way to hand around the HDC safely. I've been working with the folks at Stanford Radiology to integrate crserver and crutserver to try to work around these issues, but we keep getting stuck. Since the render SPU is dynamically loaded, it's tricky to hand off the window handle. We might have to somehow integrate the renderSPU into the crutserver to work around this. -Mike |
From: Jorge L. W. <jo...@jl...> - 2004-07-28 22:19:38
|
On Jul 28, 2004, at 2:28 PM, Christopher Waters wrote: > While I'm on the topic of Darwin, last week I made a patch to update > to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k > is too big of a file to send to the mailing list. =\ I'll most likely > flesh-out and send an updated patch later this week. I've had similar problems sending patches to this mailing list. I get a notice stating that my msg is waiting for moderator approval, but this never happens. My final solution was simply to gzip the patch. Who's the moderator? jOrGe W. |
From: Greg H. <hu...@gm...> - 2004-07-28 23:17:56
|
I'm the moderator, but I get SO MANY moderator requests that I just ignore them all. On Wed, 28 Jul 2004 15:19:27 -0700, Jorge Luis Williams <jo...@jl...> wrote: > > On Jul 28, 2004, at 2:28 PM, Christopher Waters wrote: > > > While I'm on the topic of Darwin, last week I made a patch to update > > to 'full' CGL/AGL (faker/render) support in Darwin, but apparently 43k > > is too big of a file to send to the mailing list. =\ I'll most likely > > flesh-out and send an updated patch later this week. > > > I've had similar problems sending patches to this mailing list. I get > a notice stating that my msg is waiting for moderator approval, but > this never happens. My final solution was simply to gzip the patch. > Who's the moderator? > > jOrGe W. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > -- Greg Humphreys, Assistant Professor Department of Computer Science, University of Virginia http://www.cs.virginia.edu/~humper/ |
From: Christopher W. <cr...@ms...> - 2004-07-29 17:33:32
Attachments:
darwin_patch.tar.gz
|
and here is said patch, along with renderspu_agl.c :) -Chris |
From: David J. <jo...@mc...> - 2004-07-29 21:01:40
|
I'm having the same linking problem as before with the darwin builds. Running crserver gives me: vibrio% crserver dyld: crserver can't open library: ..//built/spuload/Darwin/libspuload.dylib (No such file or directory, errno = 2) zsh: trace trap crserver And doing an 'otool -L' on crserver gives me: crserver: ..//built/spuload/Darwin/libspuload.dylib (compatibility version 0.0.0, current version 0.0.0) ../../built/crmothership/Darwin/libcrmothership.dylib (compatibility version 0.0.0, current version 0.0.0) ../built/crpacker/Darwin/libcrpacker.dylib (compatibility version 0.0.0, current version 0.0.0) ../built/crutil/Darwin/libcrutil.dylib (compatibility version 0.0.0, current version 0.0.0) ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1) Again, the cr binaries are not using absolute paths during linking which is giving me errors. -Dave On Thu, 29 Jul 2004, Christopher Waters wrote: > and here is said patch, along with renderspu_agl.c :) > > -Chris > > |
From: Christopher W. <cr...@ms...> - 2004-07-29 21:10:08
|
add your chromium lib path to the environment variable "DYLD_FALLBACK_LIBRARY_PATH" that should remedy it :) -Chris On Jul 29, 2004, at 4:01 PM, David Jones wrote: > I'm having the same linking problem as before with the darwin builds. > Running crserver gives me: > > vibrio% crserver > dyld: crserver can't open library: > ..//built/spuload/Darwin/libspuload.dylib (No such file or directory, > errno = 2) > zsh: trace trap crserver > > And doing an 'otool -L' on crserver gives me: > > crserver: > ..//built/spuload/Darwin/libspuload.dylib (compatibility > version 0.0.0, current version 0.0.0) > ../../built/crmothership/Darwin/libcrmothership.dylib > (compatibility version 0.0.0, current version 0.0.0) > ../built/crpacker/Darwin/libcrpacker.dylib (compatibility > version 0.0.0, current version 0.0.0) > ../built/crutil/Darwin/libcrutil.dylib (compatibility version > 0.0.0, current version 0.0.0) > ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib > (compatibility version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 71.1.1) > > Again, the cr binaries are not using absolute paths during linking > which > is giving me errors. > > -Dave > > > On Thu, 29 Jul 2004, Christopher Waters wrote: > >> and here is said patch, along with renderspu_agl.c :) >> >> -Chris >> >> > |
From: David J. <jo...@mc...> - 2004-07-29 21:26:12
|
Ok, now I can start it, but LoadBundle seems to be failing now. In dll.c, is this correct: >if( filename[0] != '/' ) { > /* default to a chromium bundle */ > crStrcpy( _filename, "/cr/lib/Darwin/" ); > crStrcat( _filename, filename ); > } else { > crStrcpy( _filename, filename ); > } The filename being passed is 'renderspu.bundle'. After the cpy/cat operations, it tries opening the bundle at '/cr/lib/Darwin/renderspu.bundle' I think this only works if I install chromium at root level. I'm using a copy in my home directory. -Dave On Thu, 29 Jul 2004, Christopher Waters wrote: > add your chromium lib path to the environment variable > "DYLD_FALLBACK_LIBRARY_PATH" > > that should remedy it :) > > -Chris > > On Jul 29, 2004, at 4:01 PM, David Jones wrote: > > > I'm having the same linking problem as before with the darwin builds. > > Running crserver gives me: > > > > vibrio% crserver > > dyld: crserver can't open library: > > ..//built/spuload/Darwin/libspuload.dylib (No such file or directory, > > errno = 2) > > zsh: trace trap crserver > > > > And doing an 'otool -L' on crserver gives me: > > > > crserver: > > ..//built/spuload/Darwin/libspuload.dylib (compatibility > > version 0.0.0, current version 0.0.0) > > ../../built/crmothership/Darwin/libcrmothership.dylib > > (compatibility version 0.0.0, current version 0.0.0) > > ../built/crpacker/Darwin/libcrpacker.dylib (compatibility > > version 0.0.0, current version 0.0.0) > > ../built/crutil/Darwin/libcrutil.dylib (compatibility version > > 0.0.0, current version 0.0.0) > > ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib > > (compatibility version 0.0.0, current version 0.0.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 71.1.1) > > > > Again, the cr binaries are not using absolute paths during linking > > which > > is giving me errors. > > > > -Dave > > > > > > On Thu, 29 Jul 2004, Christopher Waters wrote: > > > >> and here is said patch, along with renderspu_agl.c :) > >> > >> -Chris > >> > >> > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > |
From: Christopher W. <cr...@ms...> - 2004-07-29 22:00:13
|
Ah, I do apologize for that. I'm not aware of any way to retrieve the exact lib path, and NSCreateObjectFileImageFromFile apparantly needs the absolute path of the bundle. Perhaps you could set an environment variable to the path, and change that code to something like this: if( filename[0] != '/' ) { /* default to a chromium bundle */ char path = crGetenv("CR_LIBRARY_PATH"); /* is there already a var for this? */ crStrcpy( _filename, (path ? path : "/cr/lib/Darwin/") ); crStrcat( _filename, filename ); } else { crStrcpy( _filename, filename ); } -Chris On Jul 29, 2004, at 4:26 PM, David Jones wrote: > Ok, now I can start it, but LoadBundle seems to be failing now. > > In dll.c, is this correct: > >> if( filename[0] != '/' ) { >> /* default to a chromium bundle */ >> crStrcpy( _filename, "/cr/lib/Darwin/" ); >> crStrcat( _filename, filename ); >> } else { >> crStrcpy( _filename, filename ); >> } > > The filename being passed is 'renderspu.bundle'. After the cpy/cat > operations, it tries opening the bundle at > '/cr/lib/Darwin/renderspu.bundle' > > I think this only works if I install chromium at root level. I'm > using a > copy in my home directory. > > -Dave > > > On Thu, 29 Jul 2004, Christopher Waters wrote: > >> add your chromium lib path to the environment variable >> "DYLD_FALLBACK_LIBRARY_PATH" >> >> that should remedy it :) >> >> -Chris >> >> On Jul 29, 2004, at 4:01 PM, David Jones wrote: >> >>> I'm having the same linking problem as before with the darwin builds. >>> Running crserver gives me: >>> >>> vibrio% crserver >>> dyld: crserver can't open library: >>> ..//built/spuload/Darwin/libspuload.dylib (No such file or >>> directory, >>> errno = 2) >>> zsh: trace trap crserver >>> >>> And doing an 'otool -L' on crserver gives me: >>> >>> crserver: >>> ..//built/spuload/Darwin/libspuload.dylib (compatibility >>> version 0.0.0, current version 0.0.0) >>> ../../built/crmothership/Darwin/libcrmothership.dylib >>> (compatibility version 0.0.0, current version 0.0.0) >>> ../built/crpacker/Darwin/libcrpacker.dylib (compatibility >>> version 0.0.0, current version 0.0.0) >>> ../built/crutil/Darwin/libcrutil.dylib (compatibility version >>> 0.0.0, current version 0.0.0) >>> ../built/crunpacker/Darwin/libcrserver_crunpacker_copy.dylib >>> (compatibility version 0.0.0, current version 0.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, >>> current version 71.1.1) >>> >>> Again, the cr binaries are not using absolute paths during linking >>> which >>> is giving me errors. >>> >>> -Dave >>> >>> >>> On Thu, 29 Jul 2004, Christopher Waters wrote: >>> >>>> and here is said patch, along with renderspu_agl.c :) >>>> >>>> -Chris >>>> >>>> >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by OSTG. Have you noticed the changes >> on >> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >> one more big change to announce. We are now OSTG- Open Source >> Technology >> Group. Come see the changes on the new OSTG site. www.ostg.com >> _______________________________________________ >> Chromium-dev mailing list >> Chr...@li... >> https://lists.sourceforge.net/lists/listinfo/chromium-dev >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > |
From: Christopher W. <cr...@ms...> - 2004-07-30 19:27:38
|
Would it be possible for someone to commit this to the CVS? Perhaps with the fix I suggested to David Jones, as well. -Chris Waters On Jul 29, 2004, at 12:32 PM, Christopher Waters wrote: > and here is said patch, along with renderspu_agl.c :) > > -Chris > > <darwin_patch.tar.gz> > > On Jul 28, 2004, at 4:28 PM, Christopher Waters wrote: > >> While I'm on the topic of Darwin, last week I made a patch to update >> to 'full' CGL/AGL (faker/render) support in Darwin, but apparently >> 43k is too big of a file to send to the mailing list. =\ I'll most >> likely flesh-out and send an updated patch later this week. >> >> -Chris Waters >> |
From: Alan M. <al...@re...> - 2004-07-30 20:03:20
|
On Fri, 2004-07-30 at 15:26, Christopher Waters wrote: > Would it be possible for someone to commit this to the CVS? Perhaps > with the fix I suggested to David Jones, as well. > Send it to me and I'll put it in. > -Chris Waters > > On Jul 29, 2004, at 12:32 PM, Christopher Waters wrote: > > > and here is said patch, along with renderspu_agl.c :) > > > > -Chris > > > > <darwin_patch.tar.gz> > > > > On Jul 28, 2004, at 4:28 PM, Christopher Waters wrote: > > > >> While I'm on the topic of Darwin, last week I made a patch to update > >> to 'full' CGL/AGL (faker/render) support in Darwin, but apparently > >> 43k is too big of a file to send to the mailing list. =\ I'll most > >> likely flesh-out and send an updated patch later this week. > >> > >> -Chris Waters > >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev -- Alan Matsuoka Global Professional Services Red Hat Canada, Ltd mailto:al...@re... |