This needs to be reopened and the linkage for all X11 libraries set to "flat_namespace" (which is the way it was before the December 2001 tools).
The reason is that the applications which will use the X11 libraries are not going to know anything about X11's special need for the flat namespace. By changing the X11 libraries to use "twolevel_namespace" you have broken the API.
An example is what I'm trying to do, which is build the Eclipse IDE on Mac OS X with OpenMotif. Because I can only build a dynamic library (JNI) that uses X11/Motif, I cannot force the application (the Mac OS X Java VM) to force the use of a flat namespace.
The Java executable properly assumes that any dynamic libraries will have their namespace settings set to something that will work. So even if I could change the Java executable to force_flat_namespace, I wouldn't even want to, because there well could be other dynamic libraries which *do* use two level namespaces.
The OpenMotif library does not have a problem. It correctly does not enable two level namespaces. The problem is only in the XFree86 libraries, which are all linked with twolevel_namespace enabled.
The problem is that Apple changed the default on their linker to assume the new design, which will break all kinds of old code. But they, perhaps unreasonably, assumed that anyone using the new tools to rebuild would update their build settings appropriately. I realize that this is a confusing and somewhat subtle situation. It has cost me days to sort through all the bits and figure out what the right thing is here.
My temporary solution will be to have my launch wrapper check whether the X11 libraries have twolevel namespace enabled (which can be seen with "otool -vh /usr/X11R6/lib*.dylib"), and have an option for patching the binaries to disable twolevel if needed. Obviously not ideal.
No problem; I've reopened it. Since it was closed this bug was fixed by reverting libXt to flat. See the reopened bug for more details. Sorry for the confusion.
Okay, but I'm a bit leery of only reverting libXt. I'm no kind of X expert, but given that Xt has this legacy, I have to suspect that the technique could appear with other libraries. I think Apple was way too aggressive in introducing this change, and should have left flat namespace as the default during 10.1 and then switched to twolevel for 10.2. It seems to me that rewarding early adopters is more important than rolling out tricky new features asap.
Anyhow, I'm glad to see that this is being resolved.
Also I discovered an environment variable that solves my problem for Java (avoiding my awful binary patching plan) and may be helpful to others:
setenv DYLD_FORCE_FLAT_NAMESPACE true
Makes executables behave as though they had been linked that way. Yay for small favors. Wish this had been placed front-and-center in the Apple docs:
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.