[partitionpenguin]

Recently the SM64 PC port announced back in May has gotten some additions and tweaks in the form of a fork called sm64ex, one of them being a backend that uses legacy OpenGL (1.1) instead of the original which I believe needed 2.0. I decided it would be fun to try and compile it for IRIX on my O2. 

Well, I ran into a couple errors in my adventure so far, but I have been able to resolve all of them reasonably except for this one I encountered at linking time:

Code:

/usr/sgug/bin/ld: build/us_pc/src/pc/gfx/gfx_opengl_legacy.o: undefined reference to symbol 'glColor3f'
/usr/sgug/bin/ld: note: 'glColor3f' is defined in DSO //usr/lib32/libGLcore.so so try adding it to the linker command line
//usr/lib32/libGLcore.so: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make: *** [Makefile:990: build/us_pc/sm64.us.f3dex2e] Error 1

As far as I know, the default LDFLAGS for GL specifically in the project are just -lGL. sdl-config pulls in some libs of its own but AFAIK none of it has to do with opengl. So reading the error I figured I'd try adding GLCore. Well, this is what happens in that case 

Code:

/usr/lib32/../lib32/libGL.so: undefined reference to `XSGIMiscQueryExtension'
/usr/lib32/../lib32/libGL.so: undefined reference to `_XSGISetSpecialDestroyHandler'
/usr/lib32/../lib32/libGL.so: undefined reference to `_XSGISetSpecialDestroyInterest'
/usr/lib32/libGLcore.so: undefined reference to `gl_INTERPRET_END'
collect2: error: ld returned 1 exit status
make: *** [Makefile:990: build/us_pc/sm64.us.f3dex2e] Error 1

No re-ordering of the linker flags, or specifying the DSOs manually by their full paths, has gotten rid of both of these errors. It seems like whenever glCore is present, the latter error happens, and when it isn't, the first one always appears. Googling tells me very little about the symbols in question for the second error, and I'm thinking the reason why is because those are internal symbols that GL and GLcore use to talk to each other, and not something that's exposed. Either that or, as the name of the function suggests, they're just SGI specific extensions that very few software has used and as a result there's nothing on the internet for them. I'm thinking that glCore is not meant to ever be used directly in linker flags, but I'm still not really sure what's causing the first error. Maybe my GL setup is broken on my machine? It says it can't read the symbols from GLcore, but if I specify it explicitly, it clearly understands the file and I know it isn't corrupt. That's why I wanted to ask here, since I was wondering if anybody had seen the same type of issues when trying to compile GL programs.

FYI, this uses SGUG-RSE 0.0.6, so GCC and GNU LD.

[Raion]

It looks to me either your GL libraries are missing, or mismatched, or there's a potential problem with the dev env that you're using. I do not think it's a bug in the sgug packages, based on the error.

[jpstewart]

Interesting.  I've been poking around in the GL libraries on my Octane.  It seems libGLcore.so does have an undefined symbol gl_INTERPRET_END.  But I can't find which library it is defined in.  It must be defined somewhere!

The undefined XSGI symbols are in libXext.so.  That needs to be included in the list of libraries when you're seeing those errors.

Since partitionpenguin is using GNU ld order should not matter, but for IRIX ld libXext must be after the GL libraries.

I'm thinking that glCore is not meant to ever be used directly in linker flags

Correct.  What does 'ldd /usr/lib32/libGL.so' output?  It should list libGLcore.so as one of the libraries used by libGL -- which is exactly why you shouldn't need to add it to the linker command.  Maybe also try using IRIX ld instead, if you can.  This might be a bug in the GNU linker.

[partitionpenguin]

Interesting.  I've been poking around in the GL libraries on my Octane.  It seems libGLcore.so does have an undefined symbol gl_INTERPRET_END.  But I can't find which library it is defined in.  It must be defined somewhere!

The undefined XSGI symbols are in libXext.so.  That needs to be included in the list of libraries when you're seeing those errors.

Since partitionpenguin is using GNU ld order should not matter, but for IRIX ld libXext must be after the GL libraries.

I'm thinking that glCore is not meant to ever be used directly in linker flags

Correct.  What does 'ldd /usr/lib32/libGL.so' output?  It should list libGLcore.so as one of the libraries used by libGL -- which is exactly why you shouldn't need to add it to the linker command.  Maybe also try using IRIX ld instead, if you can.  This might be a bug in the GNU linker.

Yeah, I figured out that Xext contains the SGI extension symbols, but as you said it's unclear where gl_interpret_end is. 

I'll run that ldd command, but I'm pretty sure it's linked properly, hence why it knows to look in GLcore in the first place. Curiously, I was poking around with 'nm' and I noticed that the nm which belongs to SGUG binutils (GNU) does not read the symbols of files I specify (It says something along the lines of no symbols found.) I wonder if this has to do with GNU ld, in that it knows to look in glCore but it can't read what's inside it, and so maybe it's a bug. 

I tried IRIX ld, but it doesn't make any sense of the GNU object files and I believe the reason for that is the LTO introduced by GCC, which Raion mentioned to me. Too many errors, most of which I have no clue how to fix. I would just use MIPSPro, but I'm a little leery given the size of the SM64 codebase and my relative unfamiliarity with C programming and porting stuff to MIPSPro. Instead I'm thinking that it might be better to instead use a Nekoware GCC toolchain, maybe that LD will be a little bit more stable. In the meantime though, I'll mention this to the SGUG folks in case it is a bug.

I'll also keep this thread updated in case I find anything.

---

Oh and, I wanted to ask - as a sanity check for my own system, in case the GL libraries are broken - do you know of any good OpenGL examples that compile on IRIX and don't require external dependencies like GLUT? (Because I can't seem to figure out where to obtain that, anyway, it says it's in the freeware distribution online but I don't think I have that installed.) Maybe something that uses GLX and Xlib or Motif to grab an X context. Or even SDL, since I have that installed.

[Raion]

glxgears?

GLUT is easy to build on IRIX.

[partitionpenguin]

glxgears?

GLUT is easy to build on IRIX.

I actually downloaded a tarball and tried building it but it was nothing but errors. You're right, GLXgears could work though

[Raion]

As I said, dev environment is probably kind of fucked? Looking at the stuff RSE installs and uses, I would recommend against using Nekoware, SGUG-RSE, and your own self-compiled software in the same install. I understand you don't have many systems, but you should probably spread your installation purposes out. I even have a drive I will probably throw in the Tez or Onyx2 that will test RSE - one day when I'm bored enough to see exactly the full process. I'd like to think prefixing and possibly several shellrc or profiles would work around this, but it's not an ideal solution. Really, I believe people should choose to run either RSE, legacy Nekoware, (Insert upcoming projects here), etc - don't try to mix them. I think RSE allows for you to use SRPMs, so have you tried grabbing the GLUT/GLEW SRPMs for Fedora and using those??

I had no issue building GLUT and GLEW - if you have issues, grab the relnotes from the nekoware packages. I'm gonna one of these days split all of the relnotes and patches/src out of the legacy nekoware so people can see the painstaking documentation 15 years of work went into.

[partitionpenguin]

As I said, dev environment is probably kind of fucked? Looking at the stuff RSE installs and uses, I would recommend against using Nekoware, SGUG-RSE, and your own self-compiled software in the same install. I understand you don't have many systems, but you should probably spread your installation purposes out. I even have a drive I will probably throw in the Tez or Onyx2 that will test RSE  - one day when I'm bored enough to see exactly the full process. I'd like to think prefixing and possibly several shellrc or profiles would work around this, but it's not an ideal solution. Really, I believe people should choose to run either RSE, legacy Nekoware, (Insert upcoming projects here), etc - don't try to mix them. I think RSE allows for you to use SRPMs, so have you tried grabbing the GLUT/GLEW SRPMs for Fedora and using those??

I had no issue building GLUT and GLEW - if you have issues, grab the relnotes from the nekoware packages. I'm gonna one of these days split all of the relnotes and patches/src out of the legacy nekoware so people can see the painstaking documentation 15 years of work went into.

Maybe, after all I am using SDL from nekoware and stuff, so maybe there are conflicts. The nice thing about the way I have my O2 set up is that all of the extra environments can be launched using shell scripts that set up the env vars. Without those, the extra environments mind as well not even exist, as I do not touch LD_LIBRARY_PATH or PATH at all in my shell RC or profile. So I think my best solution might just be using everything from nekoware for now, that includes GCC, and then as you mentioned GLUT too. Only thing is Python3, that's a runtime dep and I don't have that outside of RSE.

[Raion]

Nekoware does have Python 3.1... But I understand that's far too old to do anything with. My suggestion:

Check my wiki page for building GCC 5, build it into nekoware, then try grabbing the RSE patches for Python3 manually (as well as any deps not in Nekoware) and try building it in there. The 4.7.1 should work, you may need to do a full bootstrap though...

But as much as I want to believe you when you say they don't conflict, I have seen stuff break. And while I've not tested RSE, some things like libdicl and Erno's older GCC tardists do replace or overwrite or use special headers or libs that do not function under certain assumptions, and have broken stuff for MIPSPro for me. That's why I segregate things

I'm not pushing you to not do it however you want, by any means do what you prefer and are comfortable with, but please don't mix packages or code and expect it to just work. That's pretty much asking for trouble, and very few people here are going to be able to help with the RSE side, and at SGUG, many don't even seem to acknowledge the work or strides Nekoware accomplished, let alone have used it in-depth as some of us have. That sets you and other users up for failure. That's why I say stick with things. I wish I had Nekoware II for release even in a preliminary state, but I'm not authorized by Axatax to do that yet for a variety of reasons.

I hate saying this sort of thing over and over ad nauseaum, for those who've witnessed the last time this kind of talk erupted; but it's a little too much to ask of the 'veterans' here to use a software distribution they're not interested in. It's not elitist purism. Some like myself work on or have worked on RHEL or Fedora or CentOS for years and may not really like the idea of forgoing native packaging for something straight out of GNU/Linux. I don't like RPM on AIX for the same reason. I'm not a veteran, but many of the ex-Nekochanners here are.

Hopefully that lays out the problem. I can't make promises about Nekoware II since my job is testing and packaging, but Axatax is in charge of building our "base"

[jpstewart]

Curiously, I was poking around with 'nm' and I noticed that the nm which belongs to SGUG binutils (GNU) does not read the symbols of files I specify (It says something along the lines of no symbols found.) I wonder if this has to do with GNU ld, in that it knows to look in glCore but it can't read what's inside it, and so maybe it's a bug. 

I agree.  Since GNU nm doesn't work either, it looks more like a bug in GNU binutils.  You're quite right about it being odd that it knows to look in GLcore but still can't resolve the symbols properly.

Frankly, the standard advice for a long time was that GNU ld on IRIX was broken.  I wouldn't be the least bit surprised if it still is.

Oh and, I wanted to ask - as a sanity check for my own system, in case the GL libraries are broken - do you know of any good OpenGL examples that compile on IRIX and don't require external dependencies like GLUT?

IRIX ships its own OpenGL samples in the gl_dev.sw.samples package which can be found on the Development Libraries CD and/or one of the Overlays CDs for your version of IRIX.  They install to /usr/share/src and should compile out of the box.  They might already be installed on your system.