2

I have a locally built stack project that copies an lib_.so to a shared lib directory in El Capitan. This shared object is itself linked to a number of others, all of which are .so files. I have another stack project that references the first project as a local dependency and expects to find the shared library that it copies to the said directory, except that stack looks for lib_.dylib in the shared directory and not lib_.so. It predicably fails to find the file.

Is there a way to tell stack that it should use the .so files? If I rename the root file to .dylib stack can find it but then fails to find the other linked files, all of which are expected to be .dylib.

o1lo01ol1o
  • 440
  • 1
  • 5
  • 13
  • Coming from the Stack bugtracker. Shared libraries on OS X have `.dylib` extension, not `.so`, so I'd guess there's no way to do that. I assume this is enforced by GHC. So the first question is, why are you installing a `.so` file on OS X? Then, if that `.so` is a Haskell library this is a bad setup, if it's any other library it just has a non-portable build script. – Blaisorblade Nov 21 '16 at 22:39
  • Partial retraction: http://stackoverflow.com/a/2339910/53974 suggests that `.so` is common (but non-standard) for *loadable modules/bundles*, which you can't link against (they're supposed to be loaded at runtime). But again, "It is not possible to link against bundles as if they were shared libraries." So if *that's* the case, what you're trying to do isn't supposed to work, even though this might not be your doing. – Blaisorblade Nov 21 '16 at 22:51

1 Answers1

1

If I rename the root file to .dylib stack can find it but then fails to find the other linked files, all of which are expected to be .dylib.

I'd suggest renaming all libraries to .dylib, using either https://stackoverflow.com/a/14887391/53974 or maybe https://www.tekrevue.com/tip/batch-rename-files-os-x-yosemite/ or other google results. I can't tell whether it works because it depends on how buggy the build script producing the libraries is, but your result suggest the build script might be simply using the wrong extension for shared libraries.

Community
  • 1
  • 1
Blaisorblade
  • 6,438
  • 1
  • 43
  • 76
  • 1
    Thanks for the reply: "might be simply using the wrong extension for shared libraries." Is likely the culprit, though it's not my package and it's not a simple package. I'll see if renaming all of them gets any joy. – o1lo01ol1o Nov 21 '16 at 22:58
  • I imagined. Please consider upvoting or accepting ;-). – Blaisorblade Nov 22 '16 at 13:49
  • 1
    Changing all the names did not work because of some linking quirk I don't understand. In the end, the maintainer changed the build script to generate `.so` and `.dylib` files on OSX. This fixed it. – o1lo01ol1o Nov 24 '16 at 18:43