OS X 10.4 linking issues

OpenGL Development JOGL Development
#1

The current CVS build is broken for universal binary building on OS X 10.4. We’ve tried on both PPC and x86 versions of 10.4 and identical errors result. Three different machines all are doing this. If I use the non-universal binary build then it compiles cleanly, so it appears that one ofthe libraries being pulled in is causing the problems.

If I don’t set the MACOSX_DEPLOYMENT_TARGET to 10.3, it complains about not being able to prebind and stops. If I set it to 10.3 then it fails to find _dlopen, _dlclose, dl_sym and several other libraries involved in dynamic library loading. This comes from the linking step of gluegen-rt.

Doing a little bit of research around the net, this particular problem started arising with the release of 10.4. One or more system libraries require these APIs beyond what the actually app code needed. The typical solution that worked for others was to add -ldl to the command line, which I’ve tried but hasn’t had any effect. We had this code compiling about a month ago, so I suspect that something in the most recent set of Apple updates on these machines has caused the problem. Wondering if anyone has come across this and some idea of a fix?

#2

I’m running the latest 10.4 update on the Intel Mac in my office with the XCode tools 2.2.1 and universal builds of the GlueGen, JOGL, and JOAL workspaces all work fine. What are the errors being reported by the compiler/linker?

#3

gluegen.properties and jogl.properties have the contents:

antlr.jar=/Users/justin/java/antlr-2.7.6/antlr.jar
macosxfat=true

Nothing else in either file. This is a clean download onto 3 separate machines. There was no jogl, gluegen or anything else out there and they just got updates last week. It’s not like the environment is being poluted from something else here, hence my confusion as to what is going on. I had this compiling on another machine about a month ago with no issues.

#4

What version of the XCode tools do you have installed? You should be able to find a /Development/Readme or similar indicating this.

You shouldn’t need to specify the “macosxfat” target to Ant any more. Does taking it off change anything?

What does ant -v report for the actual command line being passed to ld?

#5

I discovered the difference between the two commands over the weekend too. It seems that somehow inside the ant build scripts that calling “ant macosxfat” is not executing the same buildpath as “ant macosx” with the universal binary flag being set. Confirmed the problem on a 4th machine, so it’s definitely an build.xml problem and not the machine setup. Since the property file value is being used, the extra build target is superfluous, so I would recommend removing it.

#6

Sorry, forgot to answer the other question - all machines are running Xcode 2.3.

#7

I’ve checked in the removal of the old obsolete build targets. At this point the correct way of doing a build is simply invoking “ant”. Please post if you see further problems.

#8

Thanks for that. Everything is building nicely for us now.