cap10subtext

I'm getting an error from dlcompat.c when I try to run an external that's linking to a dylib in /usr/lib. Works fine under 10.5 and Max 5.0.8.

module = (void *)NSAddImage(path, NSADDIMAGE_OPTION_RETURN_ON_ERROR);

is returning NULL. I thought it was maybe because NSAddImage was deprecated in 10.6 but the test program still runs from the command line. It's only when I try to run it in the latest version of Max that it fails.

Any ideas why this would be happening? Did something change regarding security settings or path settings that prevents Max from loading a dylib from /usr/lib?

    NSObjectFileImageReturnCode ofirc;

    static int (*make_private_module_public) (NSModule module) = 0;

    unsigned int flags = NSLINKMODULE_OPTION_RETURN_ON_ERROR | NSLINKMODULE_OPTION_PRIVATE;

    /* If we got no path, the app wants the global namespace, use -1 as the marker

    /* Create the object file image, works for things linked with the -bundle arg to ld */

    ofirc = NSCreateObjectFileImageFromFile(path, &ofi);

        case NSObjectFileImageSuccess:

            /* It was okay, so use NSLinkModule to link in the image */

            if (!(mode & RTLD_LAZY)) flags += NSLINKMODULE_OPTION_BINDNOW;

            module = NSLinkModule(ofi, path,flags);

            /* Don't forget to destroy the object file image, unless you like leaks */

            NSDestroyObjectFileImage(ofi);

            /* If the mode was global, then change the module, this avoids

             multiply defined symbol errors to first load private then make

             global. Silly, isn't it. */

            if ((mode & RTLD_GLOBAL))

             if (!make_private_module_public)

             _dyld_func_lookup("__dyld_NSMakePrivateModulePublic",

                (unsigned long *)&make_private_module_public);

             make_private_module_public(module);

        case NSObjectFileImageInappropriateFile:

            /* It may have been a dynamic library rather than a bundle, try to load it */

            module = (void *)NSAddImage(path, NSADDIMAGE_OPTION_RETURN_ON_ERROR);

        case NSObjectFileImageFailure:

            post("Object file setup failure : "%s"", path);

        case NSObjectFileImageArch:

            post("No object for this architecture : "%s"", path);

        case NSObjectFileImageFormat:

            post("Bad object file format : "%s"", path);

        case NSObjectFileImageAccess:

            post("Can't read object file : "%s"", path);

        post("Can not open "%s"", path);

I'm getting an error from dlcompat.c when I try to run an external that's linking to a dylib in /usr/lib.  Works fine under 10.5 and Max 5.0.8.

Which means this line:
module = (void *)NSAddImage(path, NSADDIMAGE_OPTION_RETURN_ON_ERROR);

is returning NULL.  I thought it was maybe because NSAddImage was deprecated in 10.6 but the test program still runs from the command line.  It's only when I try to run it in the latest version of Max that it fails.

Any ideas why this would be happening?  Did something change regarding security settings or path settings that prevents Max from loading a dylib from /usr/lib?

/* dlopen */
void *dlopen(const char *path, int mode)
{
	void *module = 0;
	NSObjectFileImage ofi = 0;
	NSObjectFileImageReturnCode ofirc;
	static int (*make_private_module_public) (NSModule module) = 0;
	unsigned int flags =  NSLINKMODULE_OPTION_RETURN_ON_ERROR | NSLINKMODULE_OPTION_PRIVATE;

	/* If we got no path, the app wants the global namespace, use -1 as the marker
	   in this case */
	if (!path)
	{

	/* Create the object file image, works for things linked with the -bundle arg to ld */
	ofirc = NSCreateObjectFileImageFromFile(path, &ofi);
	switch (ofirc)
	{
		case NSObjectFileImageSuccess:
			/* It was okay, so use NSLinkModule to link in the image */
			if (!(mode & RTLD_LAZY)) flags += NSLINKMODULE_OPTION_BINDNOW;
			module = NSLinkModule(ofi, path,flags);
			/* Don't forget to destroy the object file image, unless you like leaks */
			NSDestroyObjectFileImage(ofi);
			/* If the mode was global, then change the module, this avoids
			   multiply defined symbol errors to first load private then make
			   global. Silly, isn't it. */
			if ((mode & RTLD_GLOBAL))
			{
			  if (!make_private_module_public)
			  {
			    _dyld_func_lookup("__dyld_NSMakePrivateModulePublic",
				(unsigned long *)&make_private_module_public);
			  }
			  make_private_module_public(module);
			}
			break;
		case NSObjectFileImageInappropriateFile:
			/* It may have been a dynamic library rather than a bundle, try to load it */
			module = (void *)NSAddImage(path, NSADDIMAGE_OPTION_RETURN_ON_ERROR);
			break;
		case NSObjectFileImageFailure:
			post("Object file setup failure :  "%s"", path);
			return 0;
		case NSObjectFileImageArch:
			post("No object for this architecture :  "%s"", path);
			return 0;
		case NSObjectFileImageFormat:
			post("Bad object file format :  "%s"", path);
			return 0;
		case NSObjectFileImageAccess:
			post("Can't read object file :  "%s"", path);
			return 0;
	}
	if (!module)
		post("Can not open "%s"", path);
	return module;
}

error-loading-dylib-in-5-1-4-on-snow-leopard

Okay, seems that the path is defaulting to just the name of the .dylib in dlcompat.c. Max (?) is finding it in /usr/lib anymore, had to fix it by concatenating the .dylib to a manual string for the path. Pain in the butt.

I still have no idea what's changed between 10.5/5.0.8 and 10.6/5.1.4 that's causing this, I can't think of what else it might be.

Okay, seems that the path is defaulting to just the name of the .dylib in dlcompat.c.  Max (?) is finding it in /usr/lib anymore, had to fix it by concatenating the .dylib to a manual string for the path.  Pain in the butt.  

I still have no idea what's changed between 10.5/5.0.8 and 10.6/5.1.4 that's causing this, I can't think of what else it might be.


Error loading dylib in 5.1.4 on Snow Leopard