MacOS nightly builds,...

[Selur]

downloaded latest nightly build and got

Selurs-Mac:mac selur$ ./tsMuxeR 
dyld: Library not loaded: /opt/local/lib/libfreetype.6.dylib
  Referenced from: /Users/selur/Downloads/bin/mac/./tsMuxeR
  Reason: image not found
Abort trap: 6

the nightly build should be a .app file build with macdeployqt like the 'build_macos_native.sh' does so that the needed libraries are shipped with the binary. (or alternatively a static build)

Cu Selur

[justdan96]

Can you suggest how the existing script should be amended?

[lighterowl]

Neither of us are MacOS developers so if you have any advice on how to make a fully static build for that platform, we're all ears.

[Selur]

Before I start let me tell you that I haven't used a mac for ~2years and I never really liked the environment, that said since I started using one in a VM environment again here's my 2cents.

Fully static is probably not feasible for tsMuxeRGUI since I think the open source Qt license wouldn't allow it + it would require that you compile your Qt binaries statically from source. It's a real hassle.

If you look at tsMuxeR using 'otool -l tsMuxeR' (iirc. ld is the tool you would use on Linux) you get:

Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /opt/local/lib/libz.1.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.2.11
compatibility version 1.0.0
Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /opt/local/lib/libfreetype.6.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 24.1.0
compatibility version 24.0.0
Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name /usr/lib/libc++.1.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 120.0.0
compatibility version 1.0.0
Load command 15
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1213.0.0
compatibility version 1.0.0

problem is that libfreetype and libz are not by default available on a Mac.
So what would be needed to at least get tsMuxeRGUI.app (which includes the tsMuxeR binary) working is that your should add a lib folder in the MacOS (or use the libs folder in the .app) and 'patch' the binary using install_name_tool to change the path.
see: https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172
So assuming you copied the dylib files to:

• tsMuxeRGUI.app/Contents/MacOS/lib/libfreetype.6.dylib and
• tsMuxeRGUI.app/Contents/MacOS/lib/lib/libfreetype.6.dylib
  calling

install_name_tool -change /opt/local/lib/libfreetype.6.dylib @executable_path/lib/libfreetype.6.dylib tsMuxeR
install_name_tool -change /opt/local/lib/libz.1.dylib @executable_path/lib/libz.1.dylib tsMuxeR

should adjust the load commands and this way fix the issue.
To be frank I'm not totally sure the call syntax is correct, since I haven't done this for quite some time, but I you get the gist of what the problem is and how it could be fixed.
(if you want to have the tsMuxeR binary outside of the .app you probably would need to create a symlink)

The general idea on mac is (at least how I got it) that:
a. like the Linux community they don't really like static builds
b. they usually don't have different versions of libraries in their system
c. to allow tools to have there own libraries the mac folks came up with .app folders which basically should provide everything that isn't naively on a may to the program. So basically apps are kind of like portable versions of tools on Windows. :)

Hope this helps a bit and didn't cause additional confusion.

[lighterowl]

Thanks for all the tips. I'm sure this will be useful once one of us gets a macOS development environment running. The general idea seems to be strikingly similar to the RPATH thing used in ELF binaries.

Fully static is probably not feasible for tsMuxeRGUI since I think the open source Qt license wouldn't allow it

Actually, Qt is licensed under GPL2/GPL3/LGPL3, all of which are compatible with Apache, which is the licence that tsMuxer is using, so this is a non-issue. Thanks for staying ahead of the game though!

a. like the Linux community they don't really like static builds

To be honest, I'm not a fan of them either, but I don't want to deal with users saying "your app doesn't work, fix it" because some dynamic library dependencies are missing from their system. ;-)

Edit : closed due to a misclick, please ignore this.

[Selur]

To be honest, I'm not a fan of them either, but I don't want to deal with users saying "your app doesn't work, fix it" because some dynamic library dependencies are missing from their system. ;-)

Same here. :)

[lighterowl]

I just pushed 7888bc6 that should fix this : the libraries that the main tsMuxeR binary depends on will now be copied into the generated zip package, and the library search paths stored inside the binary are appropriately fixed up to be @executable_path/particular_lib.dylib. I tested it on my MacOS VM with freetype uninstalled, and the new build worked, as opposed to previous ones.
We can close this once today's nightly builds pass and you independently verify that this issue is fixed.

[lighterowl]

@Selur The new build is now available, please test and report back.

[Selur]

Will test and report back this evening. Daniel Kamil Kozar <notifications@github.com> schrieb am Mo., 31. Aug. 2020, 08:38:

…

@Selur <https://github.com/Selur> The new build is now available <https://bintray.com/justdan96/tsMuxer/download_file?file_path=mac-nightly-2020-08-31--02-13-44.zip>, please test and report back. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#328 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGN66A425QGIDCUPEI755LSDNAPRANCNFSM4QPABFQA> .

[moderndeveloperllc]

I get it open. There are extra copies of the libs in the directory alongside the CLI binary and GUI. Also missing the Info.plist fixes from build_macos_native.sh, but I'm guessing that just hasn't been moved over yet.

[Selur]

close,... running otool -l on the libraries shows that they also have dependencies :/
so those dependencies also need to be copied and the libraries too need to be patched ;)

[lighterowl]

Missing the Info.plist fixes from build_macos_native.sh, but I'm guessing that just hasn't been moved over yet.

The osxcross package that the container uses for building OSX binaries on Linux does not provide the defaults or plutil programs needed for performing the necessary actions on the manifest, so this cannot be moved over until we switch to making the nightly build on a native MacOS system.

[lighterowl]

Okay, this should be fixed with the 2020-09-03 nightly. All the dependent libraries are copied and the paths changed to refer to @executable_path :

# for i in *.dylib tsMuxeR; do x86_64-apple-darwin14-otool -arch x86_64 -L "$i"; done;
libbz2.1.0.dylib:
	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
libfreetype.6.dylib:
	/opt/local/lib/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.1.0)
	@executable_path/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	@executable_path/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
libpng16.16.dylib:
	/opt/local/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
	@executable_path/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
libz.1.dylib:
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
tsMuxeR:
	@executable_path/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.1.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

install_name_tool doesn't seem capable of changing the paths of the libraries themselves, i.e. libfreetype.6.dylib still refers to /opt/local/lib/libfreetype.6.dylib and it seems like there's no way of changing that. Since my MacOS VM blew up after a recent update, I'd have to ask somebody else to test if this really works as intended.

[Selur]

will test this evening after work and report back

[Selur]

Seems to work fine.

[lighterowl]

Thanks, closing in this case.

[SubJunk]

@xavery this is either not fixed or has started happening again. Verified with nightly-2021-02-04-01-46-17