macOS fix deps path and id name for C++ binary #1051

JanX2 · 2017-12-01T12:26:16Z

On macOS 10.12.6, I tried to follow “Using the command-line client” and the native client README. I had a couple of issues getting the pre-build binaries to work. The following notes are what I did about them.

Initial Python dependencies

pip install six

Download via

python util/taskcluster.py --arch osx --target .

The native_client requires AVX2. It will crash with an “Illegal Instruction: 4” error otherwise.
Check your CPU capabilities:

sysctl -a | grep machdep.cpu.features
sysctl -a | grep machdep.cpu.leaf7_features

The latter should contain “AVX2”.

cd native_client

All dependencies that are not supplied by the system are still hard-wired to the build system’s paths.

This is how to check the dependencies of a binary:

otool -L *binary_path*

This is how to fix/patch the binaries and complete the set of required dependencies:

install_name_tool -change /Users/build-user/TaskCluster/LightTasks/1/tasks/task_1511961329/homebrew/opt/sox/lib/libsox.3.dylib @executable_path/libsox.3.dylib ./deepspeech
install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech.so @executable_path/libdeepspeech.so ./deepspeech
install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech_utils.so @executable_path/libdeepspeech_utils.so ./deepspeech
install_name_tool -change bazel-out/local-opt/bin/tensorflow/libtensorflow_cc.so @executable_path/libtensorflow_cc.so ./deepspeech

install_name_tool -id @executable_path/libdeepspeech.so libdeepspeech.so
install_name_tool -id @executable_path/libctc_decoder_with_kenlm.so libctc_decoder_with_kenlm.so
install_name_tool -id @executable_path/libdeepspeech_utils.so libdeepspeech_utils.so
install_name_tool -id @executable_path/libtensorflow_cc.so libtensorflow_cc.so

brew install libpng
brew install libmad
brew install sox

cp -pLR  /usr/local/opt/libpng/lib/libpng16.16.dylib ./
cp -pLR  /usr/local/opt/mad/lib/libmad.0.dylib ./

sudo install_name_tool -id @executable_path/libpng16.16.dylib libpng16.16.dylib
sudo install_name_tool -id @executable_path/libmad.0.dylib libmad.0.dylib

cp -pLR /usr/local/Cellar/sox/14.4.2/lib/libsox.3.dylib ./
sudo install_name_tool -id @executable_path/libsox.3.dylib libsox.3.dylib
install_name_tool -change /usr/local/opt/mad/lib/libmad.0.dylib @executable_path/libmad.0.dylib libsox.3.dylib

The following assumes this directory list within the DeepSpeech root:
native_client
smoke_test
models

Finally we can test the native_client.

./deepspeech ../models/output_graph.pb ../smoke_test/LDC93S1.wav ../models/alphabet.txt ../models/lm.binary ../models/trie

The release process should be amended to check for non-system provided dependencies and fix them like above.

The text was updated successfully, but these errors were encountered:

lissyx · 2017-12-01T12:31:24Z

@JanX2 Thanks! We would be happy to review a PR for that. There is something that I am puzzled about, because we should already have something working properly: @rpath should be already set to pick the proper libdeepspeech.so, libdeepspeech_utils.so and libtensorflow_cc.so.

JanX2 · 2017-12-01T12:37:46Z

That is really odd @lissyx! The native_client.tar.xz I got yesterday has the broken paths as per above. I just rechecked.

lissyx · 2017-12-01T12:38:24Z

@JanX2 I just tested with a build from TC (we merged tensorflow-r1.4 this morning), and indeed, seems like we have wrong path for libdeepspeech.so libdeepspeech_utils.so (and sox), but other deps are good.

lissyx · 2017-12-01T12:39:30Z

$ otool -L deepspeech 
deepspeech:
	bazel-out/local-opt/bin/native_client/libdeepspeech.so (compatibility version 0.0.0, current version 0.0.0)
	bazel-out/local-opt/bin/native_client/libdeepspeech_utils.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_cc.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_framework.so (compatibility version 0.0.0, current version 0.0.0)
	/Users/build-user/TaskCluster/LightTasks/1/tasks/task_1512084443/homebrew/opt/sox/lib/libsox.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

JanX2 · 2017-12-01T12:44:17Z

Yes @lissyx. That can’t work. I get the same.

dyld: Library not loaded: bazel-out/local-opt/bin/native_client/libdeepspeech.so
  Referenced from: …/native_client-2/./deepspeech
  Reason: image not found
Abort trap: 6

lissyx · 2017-12-01T12:45:24Z

So, @JanX2 don't hesitate to send a PR, I think we should not bundle sox and its friends, though, that should be relying on the user's system (and we document that kind of dependencies), and thanks for testing and documenting that :)

JanX2 · 2017-12-01T12:47:00Z

I agree @lissyx. Not bundling sox is fine.

But paths on the build machine like bazel-out/local-opt/bin/native_client/libdeepspeech.so will not work anywhere else.

Thank you for responding so quickly by the way!

lissyx · 2017-12-01T13:18:51Z

@JanX2 True, except I'm far from being used to the OSX linker, and its documentation is not as good as I would hope for quickly discovering, so I don't really know which magic path should be used :), so if you do, I'd really like to see a PR. If not, then I'll work on that, but later :)

JanX2 · 2017-12-01T14:28:15Z

@lissyx I don’t know about a “magic path”, but my use of install_name_tool should fix the paths to be system setup agnostic as long as the dependencies are in the same folder. :)

I don’t have a clue about the build system this project is using for the native client, but there ought to be a way to integrate the above. If all else fails, the commands I have describe above are a solution of last resort.

lissyx · 2017-12-01T14:29:33Z

Magic path in my mind are stuff like @executable_path. Besides, it should just be fixed within native_client/Makefile and maybe native_client/definitions.mk, nothing fancy.

JanX2 · 2017-12-01T17:58:27Z

@lissyx Ah. I get it. :)
@executable_path is a placeholder that will be replaced by the dynamic linker AFAIK. Any sufficiently advanced technology is indistinguishable from magic.

lissyx · 2017-12-04T09:42:08Z

Sure, but should we really use @executable_path for libs like sox? For tensorflow and others we do package, that seems right, but for others deps, I'm not so sure :[

JanX2 · 2017-12-04T12:32:36Z

@lissyx I’m pretty sure all the binaries should be using @executable_path though it’s a must for libsox.

I just added that in my OP, but I am talking solely about the pre-build binaries here.

Additionally, the .so extension is not used for dynamic libraries on macOS. It’s supposed to be .dylib as it already is for libsox.

Off the top of my hat, I blame the build system. I don’t know it at all so, to me, the white spots on my map are automatically the culprit. ;)

JanX2 · 2017-12-04T15:34:55Z

I have just tried to build Deep Speech from source. This appears to instruct the build system to build the binaries:

bazel build -c opt --copt=-O3 //tensorflow:libtensorflow_cc.so //tensorflow:libtensorflow_framework.so //native_client:deepspeech //native_client:deepspeech_utils //native_client:libctc_decoder_with_kenlm.so //native_client:generate_trie

This references the .so names directly. bagel should either name them .dylib files on macOS irregardless of the names for targets (that’s what they appear to be to me) or the targets need to be differently named on macOS if the target name and file name are hard-wired together.

lissyx · 2017-12-04T15:47:25Z

@JanX2 That's the part for TensorFlow, we don't really have a control on that.

JanX2 · 2017-12-04T15:53:28Z

@lissyx Ok. Then I would recommend to do some post-processing similar to what I have done in my original post here. Rename the binaries and patch the paths used by the dynamic linker.

I have also tried to build the binaries from source. Stuck now:
https://discourse.mozilla.org/t/build-deep-speech-from-source-macos-10-12-6/22997

lissyx · 2017-12-04T15:54:53Z

@JanX2 I have to admit I don't really see how big of a deal it is that the shared object is named .dylib instead of .so. I'm more concerned by the linkage issues, but those are easy to fix: it's in native_client/Makefile and native_client/definitions.mk :)

JanX2 · 2017-12-04T17:53:35Z

@lissyx The reason is that I want to build a macOS .framework containing everything and I don’t want any confusion in my toolchain when I get there.

I finally managed to build Deep Speech from source. The last holdup was that make deepspeech couldn’t find lib sox, because PKG_CONFIG_PATH wasn’t set for some reason. libsox and friends were installed using brew install sox. This fixed the PKG_CONFIG_PATH issue:

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/lib

Fixing the linker paths may be as simple as copying/renaming the .so files into native_client and changing the following line from definitions.mk for macOS targets:

LDFLAGS += -Wl,-rpath,. -L${TFDIR}/bazel-bin/tensorflow -L${TFDIR}/bazel-bin/native_client $(EXTRA_LDFLAGS) $(LIBS)

I have never written a file for that build system. Do you know how to copy the dynamic library .so files. Maybe even rename them in the process?

Then end result would be a directory will all necessary binaries that is moveable and largely independent of the way the system is set up.

lissyx · 2017-12-04T18:03:37Z

Thanks! I'm really puzzled how I can help: what you call "that build system" is just standard makefile, like on any simple Unix system. So you can just modify it and say add a target deepspeech.framework that would copy around files for your use case.

Regarding LDFLAGS line, is this really the way it is supposed to work on OSX, to copy around the .so? IMHO we should just add OSX-specific steps in the native_client/Makefile definition of the deepspeech target that calls install_name_tool to fix the dependencies, right?

JanX2 · 2017-12-04T18:47:10Z

@lissyx I mostly use Xcode as my IDE and rarely have to touch any text-based part of the build infrastructure it uses. It can call on make as an external build system, but that usually makes things harder when you want to debug something.

As of my last test, the binary distribution for Deep Speech had all the dependencies apart from libsox shipping with it, but they had paths to those dependencies would only work on the original build machine. That’s what I want to fix. The binary distribution should work OOTB. Without having to resort to shipping that Users folder. It’s huge and pretty messy.

And no, moving dynamic libraries around to get a working build product is not the usual way. At least you don’t do it manually. Xcode usually does this for you to bundle everything together for packaging or distribution. Just have a look an app on macOS. It’s actually a directory called a “package” you can open via the contextual menu in the Finder. Having all non-system-provided dependencies in there bundled up makes things relatively neat.

I believe you were right before when you suggested using @rpath, but I didn’t want to pile on even more dynamic linker magic (I seems just to result in the search of a list of paths) that might break. For our scenario here, @executable_path will work fine.

For my framework things might get a bit more complicated, because it might be bundled within another framework and @executable_path will not be the same there as it’s relative to the executable, not the framework binary.

lissyx · 2017-12-04T18:56:33Z

@JanX2 You are mixing things together, and this is getting confusing now: I was referring to "moving dynamic libraries" when you mentionned the LDFLAGS, I'm not even thinking about packaging yet. I still don't understand what you suggest there: copy the .so into native_client and change LDFLAGS to use a different path for linkage?

I think @rpath is safer for your framework things, however. So, I insist, it should just be a matter of fixing the deps in native_client/Makefile after building the binaries and linking with proper @rpath values. If you don't know how to hack Makefile, it's okay, I'll take care of it, but your first post suggested you had the knowledge :)

lissyx · 2017-12-04T19:00:51Z

So mostly:

install_name_tool -change /Users/build-user/TaskCluster/LightTasks/X/tasks/task_Y/homebrew/opt/sox/lib/libsox.3.dylib @executable_path/libsox.3.dylib ./deepspeech
install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech.so @executable_path/libdeepspeech.so ./deepspeech
install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech_utils.so @executable_path/libdeepspeech_utils.so ./deepspeech

JanX2 · 2017-12-04T19:10:43Z

@lissyx I find time and time again that I have no idea what I’m doing. :)

Your suggestion would assume that the .so files are all next to the deepspeech binary:

install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech.so @executable_path/libdeepspeech.so ./deepspeech install_name_tool -change bazel-out/local-opt/bin/native_client/libdeepspeech_utils.so @executable_path/libdeepspeech_utils.so ./deepspeech

The other line as well, but with the complication that the user has to provide libsox and we don’t know where it is. We can ask for it to be in a specific place. Like in /opt/sox/lib/libsox.3.dylibor next to the deepspeech binary:

install_name_tool -change /Users/build-user/TaskCluster/LightTasks/X/tasks/task_Y/homebrew/opt/sox/lib/libsox.3.dylib @executable_path/libsox.3.dylib ./deepspeech

My approach was the latter so I could move the set of binaries around. Even to another machine, if necessary.

lissyx · 2017-12-04T19:17:17Z

Now, we are on good grounds. It is supposed that deepspeech binary once distributed is bundled with the libraries, so the assumption holds. And I second you on the sox dependency ; I think we should just rely on the linker's to find it. I don't know if we need to fix the .so reference with install_name_tool.

JanX2 · 2017-12-04T19:22:15Z

We don’t need to fix the .so reference, but it would be good form to.

Additionally, the dependencies may have broken paths as per my example in the OP.

lissyx · 2017-12-04T19:24:00Z

@JanX2 .so reference is a dependency in my mind.

JanX2 · 2017-12-04T19:26:29Z

@lissyx Sorry for the misunderstanding. I read “.so reference” as changing the file names to .dylib. Not fixing the paths. But you meant the latter. Fixing the paths isn’t optional unless we want a pre-build binary that doesn’t work OOTB. ;)

Additionally, the dependencies may have broken paths as per my example in the OP.

What I meant there was that the dependencies may/do have broken paths to their dependencies and so on recursively.

lissyx · 2017-12-04T19:28:37Z

Yet,

$ otool -L deepspeech 
deepspeech:
	@rpath/libdeepspeech.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libdeepspeech_utils.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_cc.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_framework.so (compatibility version 0.0.0, current version 0.0.0)
	/Users/build-user/TaskCluster/LightTasks/5/tasks/task_1512394014/homebrew/opt/sox/lib/libsox.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

Assuming brew install sox has been performed, I get libsox.3.dylib properly loaded:

$ DYLD_PRINT_LIBRARIES=1 ./deepspeech 
dyld: loaded: /Users/tc-gh-ds/test/./deepspeech
dyld: loaded: ./libdeepspeech.so
dyld: loaded: ./libdeepspeech_utils.so
dyld: loaded: ./libtensorflow_cc.so
dyld: loaded: ./libtensorflow_framework.so
dyld: loaded: /usr/local/lib/libsox.3.dylib
dyld: loaded: /usr/lib/libc++.1.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/libc++abi.dylib
dyld: loaded: /usr/lib/system/libcache.dylib
dyld: loaded: /usr/lib/system/libcommonCrypto.dylib
dyld: loaded: /usr/lib/system/libcompiler_rt.dylib
dyld: loaded: /usr/lib/system/libcopyfile.dylib
dyld: loaded: /usr/lib/system/libcorecrypto.dylib
dyld: loaded: /usr/lib/system/libdispatch.dylib
dyld: loaded: /usr/lib/system/libdyld.dylib
dyld: loaded: /usr/lib/system/libkeymgr.dylib
dyld: loaded: /usr/lib/system/liblaunch.dylib
dyld: loaded: /usr/lib/system/libmacho.dylib
dyld: loaded: /usr/lib/system/libquarantine.dylib
dyld: loaded: /usr/lib/system/libremovefile.dylib
dyld: loaded: /usr/lib/system/libsystem_asl.dylib
dyld: loaded: /usr/lib/system/libsystem_blocks.dylib
dyld: loaded: /usr/lib/system/libsystem_c.dylib
dyld: loaded: /usr/lib/system/libsystem_configuration.dylib
dyld: loaded: /usr/lib/system/libsystem_coreservices.dylib
dyld: loaded: /usr/lib/system/libsystem_coretls.dylib
dyld: loaded: /usr/lib/system/libsystem_dnssd.dylib
dyld: loaded: /usr/lib/system/libsystem_info.dylib
dyld: loaded: /usr/lib/system/libsystem_kernel.dylib
dyld: loaded: /usr/lib/system/libsystem_m.dylib
dyld: loaded: /usr/lib/system/libsystem_malloc.dylib
dyld: loaded: /usr/lib/system/libsystem_network.dylib
dyld: loaded: /usr/lib/system/libsystem_networkextension.dylib
dyld: loaded: /usr/lib/system/libsystem_notify.dylib
dyld: loaded: /usr/lib/system/libsystem_platform.dylib
dyld: loaded: /usr/lib/system/libsystem_pthread.dylib
dyld: loaded: /usr/lib/system/libsystem_sandbox.dylib
dyld: loaded: /usr/lib/system/libsystem_secinit.dylib
dyld: loaded: /usr/lib/system/libsystem_symptoms.dylib
dyld: loaded: /usr/lib/system/libsystem_trace.dylib
dyld: loaded: /usr/lib/system/libunwind.dylib
dyld: loaded: /usr/lib/system/libxpc.dylib
dyld: loaded: /usr/lib/libobjc.A.dylib
dyld: loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
dyld: loaded: /usr/lib/libenergytrace.dylib
dyld: loaded: /usr/lib/libbsm.0.dylib
dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
dyld: loaded: /usr/lib/libz.1.dylib
dyld: loaded: /usr/lib/system/libkxld.dylib
dyld: loaded: /usr/lib/libDiagnosticMessagesClient.dylib
dyld: loaded: /usr/lib/libicucore.A.dylib
dyld: loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
dyld: loaded: /usr/local/opt/mad/lib/libmad.0.dylib
dyld: loaded: /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
dyld: loaded: /System/Library/Frameworks/Security.framework/Versions/A/Security
dyld: loaded: /usr/lib/libcoretls.dylib
dyld: loaded: /usr/lib/libcoretls_cfhelpers.dylib
dyld: loaded: /usr/lib/libOpenScriptingUtil.dylib
dyld: loaded: /usr/lib/libauto.dylib
dyld: loaded: /usr/lib/libpam.2.dylib
dyld: loaded: /usr/lib/libsqlite3.dylib
dyld: loaded: /usr/lib/libxar.1.dylib
dyld: loaded: /usr/lib/libbz2.1.0.dylib
dyld: loaded: /usr/lib/libxml2.2.dylib
dyld: loaded: /usr/lib/liblzma.5.dylib
Usage: deepspeech MODEL_PATH AUDIO_PATH ALPHABET_PATH [LM_PATH] [TRIE_PATH] [-t]
  MODEL_PATH	Path to the model (protocol buffer binary file)
  AUDIO_PATH	Path to the audio file to run (any file format supported by libsox)
  ALPHABET_PATH	Path to the configuration file specifying the alphabet used by the network.
  LM_PATH	Optional: Path to the language model binary file.
  TRIE_PATH	Optional: Path to the language model trie file created with native_client/generate_trie.
  -t		Run in benchmark mode, output mfcc & inference time

JanX2 · 2017-12-04T19:32:38Z

Thanks! DYLD_PRINT_LIBRARIES=1 seems really useful. One new thing for my tool chest. :)

LGTM so far!

Apparently it doesn’t list subdependencies. These might still have dependencies that are build-machine specific:

./libdeepspeech.so
./libdeepspeech_utils.so
./libtensorflow_cc.so
./libtensorflow_framework.so

lissyx · 2017-12-04T19:54:49Z

@JanX2 No, we don't need to worry about those, we already set proper RPATH for libtensorflow_cc.so and libtensorflow_framework.so, you are just right that we need to fix libdeepspeech.so and libdeepspeech_utils.so. One this is done, then we don't need to change the path of libsox.3.dylib since you see that it is being picked up properly by dyld. Though we may still want to change the path, for the sake of doing it properly.

And fixing the use of RPATH is likely to be a two lines patch on native_client/Makefile. Do you still want to look into that? I should be able to get on that in the next days, but before i'd like to add more resources for building for OSX so we can add C++ binary, Python and Node bindings test coverage on this platform as well.

lissyx · 2017-12-04T19:57:38Z

We might need to fix the IDs, though we build libdeepspeech.so and libdeepspeech_utils.so using TensorFlow's bazel primitives that seems to set it properly on libtensorflow_cc.so and libtensorflow_framework.so ; I might have to dig further on how they enable that, maybe we miss some definition somewhere:

ds-tc-worker:test tc-gh-ds$ otool -L libdeepspeech.so 
libdeepspeech.so:
	bazel-out/local-opt/bin/native_client/libdeepspeech.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
ds-tc-worker:test tc-gh-ds$ otool -L libdeepspeech_utils.so 
libdeepspeech_utils.so:
	bazel-out/local-opt/bin/native_client/libdeepspeech_utils.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
ds-tc-worker:test tc-gh-ds$ otool -L libtensorflow_
/Library/Developer/CommandLineTools/usr/bin/objdump: 'libtensorflow_': No such file or directory
ds-tc-worker:test tc-gh-ds$ otool -L libtensorflow_framework.so 
libtensorflow_framework.so:
	@rpath/libtensorflow_framework.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
ds-tc-worker:test tc-gh-ds$ otool -L libtensorflow_cc.so 
libtensorflow_cc.so:
	@rpath/libtensorflow_cc.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_framework.so (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)

lissyx · 2017-12-04T20:14:04Z

Okay, just -Wl,-install_name,@rpath/lib.so: https://github.com/mozilla/tensorflow/blob/master/tensorflow/BUILD#L617

Fixes mozilla#1051

lissyx · 2017-12-05T10:14:26Z

@JanX2 I've started a PR #1071 that should set things straights :)

lissyx · 2017-12-05T10:40:24Z

@JanX2 With that PR:

$ otool -L deepspeech 
deepspeech:
	@rpath/libdeepspeech.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libdeepspeech_utils.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_cc.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtensorflow_framework.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libsox.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
ds-tc-worker:test tc-gh-ds$ ./deepspeech 
Usage: deepspeech MODEL_PATH AUDIO_PATH ALPHABET_PATH [LM_PATH] [TRIE_PATH] [-t]
  MODEL_PATH	Path to the model (protocol buffer binary file)
  AUDIO_PATH	Path to the audio file to run (any file format supported by libsox)
  ALPHABET_PATH	Path to the configuration file specifying the alphabet used by the network.
  LM_PATH	Optional: Path to the language model binary file.
  TRIE_PATH	Optional: Path to the language model trie file created with native_client/generate_trie.
  -t		Run in benchmark mode, output mfcc & inference time

JanX2 · 2017-12-05T11:28:54Z

I think that’s a good start. There still are two issues I can see:

We should not change the libraries in place but copy them next to deepspeech into the native_client directory. We might otherwise break other stuff relying on the setup being as it is. Especially regarding libsox. This is fine, if we are in our own little sandbox, but we may not be.
The libraries themselves need to be fixed. This is covered by https://github.com/mozilla/tensorflow/blob/master/tensorflow/BUILD#L617 correct?

lissyx · 2017-12-05T11:38:33Z

@JanX2

For (1), I either disagree or don't understand. Everything is bundled together as native_client.tar.xz. It does work.

For (2), there is nothing to fix, as you point out and as you can see with otool, they are already properly defined.

JanX2 · 2017-12-05T11:41:09Z

@lissyx Yes. It does work. But you might prevent libsox from working correctly on the build machine. For example, I might be puzzled afterwards, if something linking against lib sox doesn’t work on my build machine. This might be fine for the tensorflow libraries, but for libsox, which my be outside of our directory hierarchy it may not.

reuben · 2017-12-05T11:47:04Z

That code isn't changing libsox, it's changing the deepspeech binary.

JanX2 · 2017-12-05T11:52:51Z

My bad. You are right of course! :D

lock · 2019-01-03T08:04:36Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

lissyx changed the title ~~macOS 10.12.6 pre-built native client issues~~ OSX fix deps path and id name for C++ binary Dec 1, 2017

lissyx added bug good first bug help wanted labels Dec 1, 2017

JanX2 changed the title ~~OSX fix deps path and id name for C++ binary~~ macOS fix deps path and id name for C++ binary Dec 1, 2017

lissyx pushed a commit to lissyx/STT that referenced this issue Dec 5, 2017

Improve OSX linkage

0c6e2a1

Fixes mozilla#1051

lissyx mentioned this issue Dec 5, 2017

Improve OSX linkage #1071

Merged

lissyx pushed a commit to lissyx/STT that referenced this issue Dec 5, 2017

Improve OSX linkage

8661d48

Fixes mozilla#1051

lissyx self-assigned this Dec 5, 2017

lissyx closed this as completed in #1071 Dec 5, 2017

lock bot locked and limited conversation to collaborators Jan 3, 2019

macOS fix deps path and id name for C++ binary #1051

macOS fix deps path and id name for C++ binary #1051

Comments

JanX2 commented Dec 1, 2017 • edited Loading

lissyx commented Dec 1, 2017

JanX2 commented Dec 1, 2017

lissyx commented Dec 1, 2017

lissyx commented Dec 1, 2017

JanX2 commented Dec 1, 2017 • edited Loading

lissyx commented Dec 1, 2017

JanX2 commented Dec 1, 2017 • edited Loading

lissyx commented Dec 1, 2017

JanX2 commented Dec 1, 2017 • edited Loading

lissyx commented Dec 1, 2017

JanX2 commented Dec 1, 2017 • edited Loading

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

JanX2 commented Dec 4, 2017

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

lissyx commented Dec 4, 2017

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

lissyx commented Dec 4, 2017

JanX2 commented Dec 4, 2017 • edited Loading

lissyx commented Dec 4, 2017

lissyx commented Dec 4, 2017

lissyx commented Dec 4, 2017

lissyx commented Dec 5, 2017

lissyx commented Dec 5, 2017

JanX2 commented Dec 5, 2017

lissyx commented Dec 5, 2017

JanX2 commented Dec 5, 2017 • edited Loading

reuben commented Dec 5, 2017

JanX2 commented Dec 5, 2017

lock bot commented Jan 3, 2019

JanX2 commented Dec 1, 2017 •

edited

Loading

JanX2 commented Dec 1, 2017 •

edited

Loading

JanX2 commented Dec 1, 2017 •

edited

Loading

JanX2 commented Dec 1, 2017 •

edited

Loading

JanX2 commented Dec 1, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 4, 2017 •

edited

Loading

JanX2 commented Dec 5, 2017 •

edited

Loading