spurious link warnings

Dear Lazyweb,

Any time I compile an X11 OpenGL program on MacOS 10.4.2, I get a slew of warnings of the form:

gcc -o ... -L/usr/X11R6/lib -lGL -lGLU -lXt -lX11 -lXmu
/usr/bin/ld: warning multiple definitions of symbol _glPointParameteri
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib(gll_api.o) definition of _glPointParameteri
/usr/X11R6/lib/libGL.dylib(dri_dispatch.o) definition of _glPointParameteri

They appear to be harmless, but I'd like to make them go away anyway. How?

Update: It seems like "-bind_at_load -multiply_defined suppress" is the proper incantation, though that may be hiding warnings that matter. I suspect not, though.

Tags: , , , ,

13 Responses:

  1. bitpuddle says:

    Do you have Fink installed on this machine?

  2. duskwuff says:

    Appears to be harmless. Incidentally, I'm able to compile GLX applications just fine without Fink installed - what are you using it for? GLUT?

    • duskwuff says:

      Oh, duh, you figured that out already. Adding -bind_at_load to the link command as suggested will make most of the errors go away; adding -multiply_defined suppress will take care of the rest. It may hide some real, important errors, though, so watch out.

      • jwz says:

        What real errors would that hide? With those args, you still get an error if foo() is defined in two different .o files, for example.

        • duskwuff says:

          You don't get an error if you redefine a function that's present in a library. On the other hand, that might not be all that bad after all.

          Enjoy. Might want to report this to Apple as a bug, as it's probably not supposed to do this, but that's your call.

    • jwz says:

      Yes, I know they appear to be harmless. That's why I said "they appear to be harmless."

      To build xscreensaver, I need all kinds of crap installed, from gtk to xml2 and back again. Fink is the path of least pain.

      • duskwuff says:

        See above. And ok, gotcha on the whole GTK/XML/KITCHENSINK mess, that's sensible enough. The dependency tree on that stuff is a mess.

  3. tkil says:

    I haven't done this myself, so if you want to filter on that and skip this message, please do so. (I do have an OSX machine, I'm just not in any shape to try to do builds on it. *hic*)

    If your executables do not need to interact with OSX in particular, you might want to try excluding the Apple framework libraries entirely; since you do not explicitly call them out, I'm assuming that OSX's gcc is told to suck them in anyway, so you will have to remove all standard libraries then add back in /lib and /usr/lib (at the least).

    Maybe a different solution would be to give the libraries with their full path instead of relying on "-l" resolution?

    I also saw a suggestion to rename the GL library in /usr/X11R6/lib to "libx11GL.dylib" and [presumably] change "-lGL" to "-Lx11GL" ... but I've no idea how much violence that'd do to your build script. (I feel a bit dirty even for repeating it.) And yes, that suggestion was for the other way around (when someone wanted the Apple Frameworks version and the X11 library was getting in the way. *shrug*

    Good luck, and thanks for your fine work on xscreensaver in the past.

    • scullin says:

      There unfortunately doesn't seem to be any non-hacky way around this. Apple's ld insists on searching the default framework libraries, which have the standard Apple OpenGL library, which happens to have the same name as their X11 OpenGL library, since that appears to be what people want to call the GL library. And although there are ways to add to the framework search path, there doesn't appear to be a documented way to subtract from it. I'm pretty sure renaming or moving either of the libraries is just an invite to a world of hurt, so you'll get to see that message unless Apple decides to put that feature into ld. Providing the complete path instead of -LGL is about all you can do.