ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib
The Apple Developer Technical Q&A on this problem http://developer.apple.com/qa/qa2007/qa1567.html says the fix is to add this to LDFLAGS: -dylib_file FILE:FILE where "FILE" is "/System/Library/Frameworks/OpenGL.framework/Versions/ A/Libraries/libGL.dylib" These ports do it this way: djvulibre, enblend, fox, fxscintilla, gst- plugins-bad, py25-gtkglext, xforms However we have some ports that instead add this to LDFLAGS: -Wl,-dylib_file,FILE:FILE These ports do it this way: aqbanking, geomview, glut, gtkglarea2, gvemod-cplxview, gvemod-crayola, gvemod-labeler, gvemod-ndview, gvemod-xforms-example, gvemodules-xforms, gwyddion, koffice, maniview, orrery, scribus What's the difference? Which one is better and why? If neither is better, why aren't we always doing it the Apple-recommended way?
Ryan Schmidt wrote:
What's the difference? Which one is better and why? If neither is better, why aren't we always doing it the Apple-recommended way?
It's the same thing, just that sometimes it won't recognize "unknown" linker flags so you wrap them in the -Wl param... Same goes with for instance "-Wl,-framework,Carbon" and so on. Does it really matter if one says tomato and the other tomato ? --anders
On Feb 20, 2008, at 06:04, Anders F Björklund wrote:
Ryan Schmidt wrote:
What's the difference? Which one is better and why? If neither is better, why aren't we always doing it the Apple-recommended way?
It's the same thing, just that sometimes it won't recognize "unknown" linker flags so you wrap them in the -Wl param...
Same goes with for instance "-Wl,-framework,Carbon" and so on. Does it really matter if one says tomato and the other tomato ?
Nope, I just wanted to understand the problem, and I don't have Leopard so I can't test it myself, and the Apple article made no mention whatsoever of the -Wl variant. Thanks for the explanation. I'll submit feedback to Apple to ask them to add it to the article.
participants (2)
-
Anders F Björklund
-
Ryan Schmidt