Running Ubuntu 64-bit, Can''t Get Imgtec Sdk To Do Anything

[lulzfish]

I got the OpenGL ES SDK from imagination technology's website, and I'd like to write programs that will run with a simulated OGLES 2.0 library.

But it looks like everything in the SDK is 32-bit, and I have no idea what I need to do to get 64-bit versions.

I tried to run 'make' from one the directories recommended by the incredibly sparse instructions, but it said gnu/stubs-32.h or something couldn't be found.

Has anybody else tried the imgtec SDK on a 64-bit Linux OS?

 

[Username]

Hmm, why are you running 64-bit I wonder?

 

[Vorporeal]

Make sure you've got the 32-bit compatibility devel libs installed.

 

[lulzfish]

So I can process 32 bits of data WHILE I process 32 bits of data...
I dunno, I have a Core 2 and it seems like a shame to waste half my data path, right?

Unless a benchmark can show that general computing is actually faster on 32-bit?
I have another distro upgrade planned soon, since I managed to break PulseAudio by being stupid. I might go back to 32-bit. Who knows.

 

[renwils]

So I can process 32 bits of data WHILE I process 32 bits of data...
I dunno, I have a Core 2 and it seems like a shame to waste half my data path, right?

Unless a benchmark can show that general computing is actually faster on 32-bit?
I have another distro upgrade planned soon, since I managed to break PulseAudio by being stupid. I might go back to 32-bit. Who knows.

Don't worry, PulseAudio is broken by default in Ubuntu. I run 64-bit as well, and it seems like the only time I ever get any use out of it is with mencoder.

 

[Exophase]

So I can process 32 bits of data WHILE I process 32 bits of data...
I dunno, I have a Core 2 and it seems like a shame to waste half my data path, right?

Heh, datapath. Being 64bit won't make most programs any faster. Having all those extra registers that x86-64 offers, on the other hand, probably will.

 

[lulzfish]

I don't know much about architecture, it just seemed like a good idea, since I've already got a 64-bit processor.

Right now it seems to be caught on this gnu/stubs-32.h thing, does anybody know what that is?

 

[Archaemic]

Well, what's the error? Telling us which file is generally less helpful than the error the file produces.

 

[lulzfish]

Well, I've given up now, but I was trying to compile the shader demo.
It started the makefile and errored looking for stubs-32.h.

I installed some 32-bit compatibility packages and it got a bit further, but then something else happened.
It might be that it needs the libraries in 32-bit, but the SDK is really hard to understand, it's not organized intuitively.

I just gave up... I'll wait for the Pandora and develop then. <_< meh.

 

[Vorporeal]

Try installing a 32-bit linux distro onto a flash-drive for development purposes. That'll allow you to keep your 64-bit installation, but still be able to do your development in a 32-bit environment and not have to worry about 32-bit/64-bit incompatibility.

 

[lulzfish]

I actually have Knoppix on a flash drive, but I don't want to bother rebooting every time, and it's not even set up right, I don't have a persistent home directory or anything.

In fact, if Knoppix is all open-source, it doesn't even have OpenGL drivers installed for my graphics card.

Virtualizing wouldn't be too much trouble, but I don't know of a program that can virtualize OpenGL.

I've also heard of using chroot for 32-bit stuff, but I was hoping for something simpler. Like.. just compiling a 64-bit version of their libraries. >_>

 

[ldesnogu]

I had no issue running the SDK on my old Fedora 7 64-bit.

Two things to help you:
- type stubs-32.h in Google and start looking
- in my system:
CODE
$ rpm -qf /usr/include/gnu/stubs-32.h
glibc-devel-2.6-4


Don't give up

BTW if your graphics card doesn't support OpenGL >= 1.5 you won't be able to play with the GL ES 2.0 SDK.

 

[dflemstr]

Two things to help you:
- type stubs-32.h in Google and start looking
- in my system:
CODE
$ rpm -qf /usr/include/gnu/stubs-32.h
glibc-devel-2.6-4

I also have this problem all the time, and in Fedora I just do "yum provides */stubs-32.h" and install the package that yum tells me to
I think all package managers have a similar feature.

And DON'T switch from 64-bit, there's really no advantages switching to 32-bit except maybe not having to handle 32-bit dependencies, but on Fedora I just do "ldd <.so that needs a dep>" and install the mentioned .so's, so it's just a small disadvantage.

 

[lulzfish]

When I try to compile the demos, it says "skipping incompatible liboglestools.a when searching for -loglestools", then it says "cannot find -loglestools"

Am I supposed to re-compile the libraries first?
I went to the directory that looks like where I'd compile it from [$SDK/Builds/OGLES2/LinuxGeneric] but it just says "no targets specified, no makefile found, stopping"

 

[dflemstr]

When I try to compile the demos, it says "skipping incompatible liboglestools.a when searching for -loglestools", then it says "cannot find -loglestools"

Am I supposed to re-compile the libraries first?
I went to the directory that looks like where I'd compile it from [$SDK/Builds/OGLES2/LinuxGeneric] but it just says "no targets specified, no makefile found, stopping"



Seems that oglestools.a was compiled already (in 32-bit) by ImgTec and you can't recompile it.
I would suggest compiling the whole SDK to 32-bit (pass -m32 to the configure script should work) and then doing all the development in 32-bit mode (again, use -m32 in your makefiles, calls to gcc etc)

But this is very strange, I use 64-bit and I compiled this thing without problems. (it was a while ago but still)

 

[ldesnogu]

When I try to compile the demos, it says "skipping incompatible liboglestools.a when searching for -loglestools", then it says "cannot find -loglestools"

Am I supposed to re-compile the libraries first?
I went to the directory that looks like where I'd compile it from [$SDK/Builds/OGLES2/LinuxGeneric] but it just says "no targets specified, no makefile found, stopping"


That's IMGtec's fault
Change this in Builds/OGLES2/LinuxGeneric/make_demo.mak:
CODE
@$(PLAT_CPP) -o $(PLAT_OBJPATH)/$(OUTNAME) $(OBJECTS) $(LINK) $(PLAT_LINK)
->
@$(PLAT_CPP) -m32 -o $(PLAT_OBJPATH)/$(OUTNAME) $(OBJECTS) $(LINK) $(PLAT_LINK)



EDIT: Cleaner:
In Builds/OGLES2/LinuxPC/make_platform.mak
CODE
PLAT_LINK = $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(X11_LIBS)
->
PLAT_LINK = -m32 $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(X11_LIBS)

 

[dflemstr]

EDIT: Cleaner:
In Builds/OGLES2/LinuxPC/make_platform.mak
CODE
PLAT_LINK = $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(X11_LIBS)
->
PLAT_LINK = -m32 $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(X11_LIBS)



Yeah that's cleaner than my version, so go for that.
Just remember that you are compiling the SDK in 32-bit mode!

 

[cb88]

Virtualbox has virtual opengl now... since version 2.2

you probably need newer xorg though I couldn't get it working with slack 12 which has xorg 1.4.2 probably needs 1.5 I hear compiz works on ubuntu with it

Virtualbox on vista running ubuntu 8.10 w/ compiz you have to install the guest additions in the virtualised ubuntu to get 3d also make sure you set the video driver to vboxvideo i think in your xorg.conf
CODE
http://www.youtube.com/watch?v=QHAgYLXQ03U&NR=1

 

[dflemstr]

Virtualbox has virtual opengl now... since version 2.2

you probably need newer xorg though I couldn't get it working with slack 12 which has xorg 1.4.2 probably needs 1.5 I hear compiz works on ubuntu with it

Virtualbox on vista running ubuntu 8.10 w/ compiz you have to install the guest additions in the virtualised ubuntu to get 3d also make sure you set the video driver to vboxvideo i think in your xorg.conf
CODE
http://www.youtube.com/watch?v=QHAgYLXQ03U&NR=1


Sometimes it works and sometimes it doesn't... This is a new technology from sun and doesn't work all the time. For example, on my Fedora 10 x86_64 VM, Xorg 1.5.3, the vboxvideo_drm.so doesn't get compiled at all for some unknown reason (I've checked the logs but can't find the problem) so yeah, sometimes you're just out of luck. Would be pretty good, though, if you would be able to debug OpenGL inside a VM.

 

[sindbad]

Would be pretty good, though, if you would be able to debug OpenGL inside a VM.
Since vmware bought Tungsten Graphics, they might integrate Gallium3D into their VMs. If not, someone else will do it, since it's probably the best way to do such things. Nothing available right now, though.