dyld: Library not loaded: /usr/local/opt/libsndfile/lib/libsndfile.1.dylib #4007
Comments
|
Can report the same thing with supernova too: otool shows the hardcoded path: and here for supernova: |
mossheim
added
comp: build
|
This should be easy to fix - just run fixup_bundle on scsynth and supernova. |
|
this is an urgent one since the beta is broken -- if someone with macOS would like to try out |
|
Sorry, I would like to fix this, but I think I do not correctly understand it. |
|
I have a mac, but did not really understand how to do it from the link brian gave
- can try it if someone explains to me how :-)
best a
… On 23/08/2018, at 02:53 , prko ***@***.***> wrote:
Sorry, I would like to fix this, but I think I do not correctly understand it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
example usage is shown in the link. you will need to find some place in the CMakeLists to make the call, my guess would be just after macdeployqt is invoked. it's not as if I know exactly what to do, this is just a hunch and it's going to take trial and error. |
|
ok thanks @brianlheim, can try that tonight
… On Aug 23, 2018, at 12:42, Brian Heim ***@***.***> wrote:
example usage is shown in the link. you will need to find some place in the CMakeLists to make the call, my guess would be just after macdeployqt is invoked. it's not as if I know exactly what to do, this is just a hunch and it's going to take trial and error.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
ok, got the dylib lookups fixed on my local copy of SC: Before putting those fixups in the the CMake script, I was wondering whether this is really the best way to go, and it seems to me that compiling scsynth and supernova to to completely independent is actually preferable. I.e. if we compile all external libs into the scsynth and supernova binaries, then they can be used really flexibly, e.g. also as sound engine for non-sclang frontends and standalones. Is this correct, or am I missing anything here? |
|
That is what fixup_bundle does, it runs otool and install_name_tool programmatically to fix paths in executables, and also verifies that the paths are correct afterwards. And no, statically linking each of these libraries into each of 3 executables is not the way to go, that's just bloat. I'm assuming that's what you mean by "compile into". If you want to distribute these binaries as separate programs for macOS the best thing to do would be to register them as packages with homebrew and list the relevant dylibs as dependencies. If you really want to support statically linking you can add a separate config flag in our project to do so, but I do not support this because it is more to maintain for dubious benefit. |
|
@brianlheim - thanks for the background info, so dylibs it is. In the CMake scripts, I don't see where best to do the fixups, Here is the list of all the library paths that I fixed upby hand A similar path error causes the help browser to fail: The likely fix seems to be to set the proper depth for all these paths: is: @loader_path/../../../../../../../QtQuick.framework/Versions/5/QtQuick |
|
@adcxyz The last error you're getting because you're breaking symlinks inside the app bundle. Those relative paths are correct, but you must be putting it through some operation that resolves symlinks to their targets. It looks in this case like you might be moving it onto some networked filesystem? |
|
I am going to work on this on my flight later today. |
|
i am putting it in the filesharing system Seafile; but I had nonworking help with just the freshcompile iirc.
On Aug 26, 2018, at 18:36, Brian Heim ***@***.***> wrote:
I am going to work on this on my flight later today.
thanks, thats great!
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
ok thanks!
that explains the growing app size ...
should not play a role for the external lib links,
will a/b check whether and how it affects the qt internal links.
… On Aug 26, 2018, at 19:04, Brian Heim ***@***.***> wrote:
http://blog.programster.org/seafile-and-symlinks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
how goes? hate to crack the whip, but if this is as serious as i think it is, it's a showstopper for 3.10-beta2. |
|
Brian wrote that he would look ainto it on a plane trip ...
Here is a quick test whether it still has the known local dev libs
that will be missing on a default macOS system:
(
[
(String.scDir +/+ "supernova"),
(String.scDir +/+ "scsynth"),
(String.scDir +/+ "plugins/DiskIO_UGens.scx"),
(String.scDir +/+ "plugins/DiskIO_UGens_supernova.scx")
].do { |binstr|
var depLines;
"*** checking dependencies for % :\n".postf(binstr.basename);
depLines = unixCmdGetStdOut("otool -L" + binstr).split($\n);
// quick and dirty test: post the known bad library paths
depLines.select(_.contains("/usr/local/opt")).postln;
}; "";
)
A fresh compile of current develop still has them ...
best adc
… On 31/08/2018, at 23:05 , Nathan Ho ***@***.***> wrote:
how goes? hate to crack the whip, but if this is as serious as i think it is, it's a showstopper for 3.10-beta2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I am not actively working on this. |
|
@brianlheim
Did you find any time at all to look into this? |
|
I don't have any further comments on this right now. I understand this is a pressing issue for the project but I simply don't have the energy to work on it in the immediate future. |
|
sure, no problem - hopefully someone with better cmake knowledge than me has time soon to solve this. |
Adds 4 new executables to macdeployqt command: scsynth, supernova, and DiskIO plugins. A quick-fix for supercollider#4007.
Adds 4 new executables to macdeployqt command: scsynth, supernova, and DiskIO plugins. A quick-fix for supercollider#4007.
Adds 4 new executables to macdeployqt command: scsynth, supernova, and DiskIO plugins. A quick-fix for supercollider#4007.
|
The commit referenced above might be a temporary solution. It adds some --executable paths (scsynth, supernova and DiskIO plugins) to the macdeployqt command in editors/sc-ide/CMakeLists.txt, which seems to be the place where the bundle is created and fixed-up. It's a bit of a kludge, but seems to do the job. |
|
@jpburstrom I think that should work for our default builds! However can you test with a build with -DSUPERNOVA=OFF? I'm not sure if macdeployqt will consider missing executables a failure or not. If it does, you will need to use a generator expression or something similar to check for that. We should also call verify_app (from BundleUtilities) on the package after running macdeployqt. Even if we don't use fixup_bundle. I regret not adding that call in when I reworked this code earlier this year. |
|
@brianlheim Thanks for the feedback. I've made a pull request. I've tested with and without supernova, and it seems to be ok. But as stated in the pull request, I don't know if macdeployqt in other qt versions behaves differently. I've also added a verify_app call. It works fine, but from the output it seems like it just checks the executables, and not the plugins, which might be an issue in the long run. |
Yes, that's true, and there doesn't seem to be a way around it. Since this is only going to run on macOS we could just roll our own verification as a shell script, something like what I gave here: #4047 (comment) Thanks again! Closed in #4047. |
Environment
Steps to reproduce (for bugs)
In SC-IDE
s.bootIn terminal
/Applications/SuperCollider/SuperCollider.app/Contents/MacOS/sclangs.bootError message (for bugs)
Expected Behavior
The server must boot.
Current Behavior
The server does not boot.
The text was updated successfully, but these errors were encountered: