[Fwd: Re: Trouble with libgsm on Mac OS X 10.6.2]

Questions about Wine on macOS.
Locked
James McKenzie

[Fwd: Re: Trouble with libgsm on Mac OS X 10.6.2]

Post by James McKenzie »

James McKenzie wrote:
rwoodsmall wrote:
James McKenzie wrote:
doh123 wrote:

Doh123:
Yes it does. Look it up for FreeBSD.

James:

No it doesn't. Like doh123 said run 'man dyld.' Mac OS X/Darwin
uses it's own C library and kernel, with bits of Free/Net/OpenBSD
mixed in. But more importantly to this discussion, it uses its own
dynamic linker - dyld. LD_LIBRARY_PATH doesn't do anything on OS X.
Saying it does doesn't make it so. The equivalent environment vars
are DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH. Again, a quick
look at the dyld man page would have told you that.

Grow a clue and stop giving advice until you do. It's getting old.
I'm pulling this from another source. Thank you for the correction.
I'll give the source a pointer in the right direction. I guess I'm
mixing Solaris/RedHat and Macs again...(Apples and whatever.)

Interestingly enough, LD_LIBRARY_PATH seems to work on my Mac. I'll
fix that though.
Now, here is something completely different:

Build Wine using scripts to build dependencies and place them in
$BUILDDIRECTORY/usr/bin...lib....etc...so on and so forth.

Run any of the tests (riched20, gdi32, etc.) WITHOUT setting the
LD_LIBRARY_PATH, but setting the DYLD_LIBRARY_PATH:

and I get the following:

err:module:load_builtin_dll failed to load .so lib for builtin
L"gdi32.dll":
dlopen(/Users/jamesmckenzie/darwine/wineEnv/src/wine-1.3.2.1/dlls/gdi32/gdi32.dll.so,
258): Symbol not found: __cg_jpeg_resync_to_restart
Referenced from:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/V
err:module:import_dll Loading library gdi32.dll (which is needed by
L"H:\\darwine\\wineEnv\\src\\wine-1.3.2.1\\dlls\\gdi32\\tests\\gdi32_test.exe")
failed (error c000007a).
err:module:LdrInitializeThunk Main exe initialization for
L"H:\\darwine\\wineEnv\\src\\wine-1.3.2.1\\dlls\\gdi32\\tests\\gdi32_test.exe"
failed, status c0000135

repeated for pages and pages.

Run the tests BUT use LD_LIBRARY_PATH:

All is well, no errors except test errors.

Interesting, eh?

This is why I made the statement earlier about using LD_LIBRARY_PATH. I
know that I'm not the only one to suffer with this. Any idea why this
does not work?

If necessary, we can move this to the development mailing list and away
from here.

I agree, this SHOULD WORK with the DYLD and not the LD given what I read
from the man page(s).


And yet even more:

If I don't set any LIBRARY_PATH, I get fontconfig errors and more tests fail.

As I stated, strange as the executables are mach-o 32 bit (I don't build 64 bit, yet) and the libraries are mach-o (dylib), not .so files.

James McKenzie
doh123
Level 8
Level 8
Posts: 1227
Joined: Tue Jul 14, 2009 1:21 pm

Post by doh123 »

I'm far from an expert on the subject matter. Maybe some app that was written for Linux/BSD or whatever is looking at a LD_LIBRARY_PATH on its own and its nothing to do with the OS? I've never tried messing with LD_LIBRARY_PATH on OSX, but its not *supposed* to do anything normally.

The OS Relies on DYLD_LIBRARY_PATH. If you change it, you have to make sure it encompasses every single location for every library accessed... or there are major issues. This is what makes DYLD_FALLBACK_LIBRARY_PATH very useful. If the library isn't found, it'll check the fallback locations. Usually its best to not mess with DYLD_LIBRARY_PATH.... but being a fallback, if a user actually has the file on their machine in a normal location, it can cause problems making anything portable, because it goes with the one it finds first.

You might want to use otool on your binaries and dylibs and see what exact location they are looking for things in. You can also use install_name_tool to modify them to look in other places. Very useful tools to change things around after they are built.
Locked