Linux and Mac TODO

[Mbucari]

Linux

• Saving and restoring window size and position doesn't seem to work.
• Make a .deb package and upload it to Launchpad. That will solve the install/update problem because users will just use apt-get.

Mac

• Mp3 is unavailable. This fix will require making an aac decoder for mac and then tracking down and adding the mac version of libmp3lame.
• Figure out how to code sign the executables so users don't have to disable developer verification to use the app. This will enrolling in the Apple Developer Program. TBH this seems onerous and maybe impossible without owning a mac.
• Sillilar the the above point, we need to make an installer and updater for macOS. I don't know much about Linux, and I know even less about Mac. Maybe we need to reach out to other open source devs who support macOS and see how they do it.
• ~Add command to open the file explorer to a folder (Go.To replacement)~ https://github.com/Mbucari/Libation/commit/d884d34c5b61c95c9341ff2524bc1b701281093f

Both

• The Expand/Collapse Process Queue symbols ( ❱❱❱ ❰❰❰ ) are Unicode and don't display properly. Replace with images.
• Add the Illegal Character Replacement dialog. This is a problem because Avalonia doesn't support Unicode, so the defaults don't display properly.

[sammcj]

Hey @Mbucari - have you had a look at some automated options for code signing?

The one that popped to mind is using Github Actions which has macOS runners with something like this - https://github.com/marketplace/actions/code-sign-action

Great project by the way!

[rmcrackan]

@Mbucari is this still an active to do list? Or is it stale?

[Mbucari]

is this still an active to do list? Or is it stale?

Sorry I missed that. Yes, it's stale.

[timdmackey]

Thanks to those involved for your work on making this app cross-platform! I discovered Libation yesterday and was happy to be able to backup my Audible library to my mac.

I see that this issue is closed, but my question is closely related so I didn't want to open a new issue unnecessarily.

Once it's set up, the app works great on MacOS, but the process of running the app could definitely be improved. The following issues could be solved by having the app live in an .app bundle:

• Can't add Libation to the Dock
• Need to sort through 300 files to find the executable each time
• Shortcuts to the executable don't reflect the correct icon, even if a custom icon is added to the executable
• (enhancement, unsure if this is fixable) Terminal shows up on the screen every time the app is opened

I was curious whether it would be possible for me to bundle the app myself, and found this document from Avalonia: https://docs.avaloniaui.net/docs/distribution-publishing/macos. I haven't read over it closely enough to know if I can do the app bundling myself, but I'm curious whether this is something that could be added to the build process to provide a proper .app bundle for Mac?

Code signing is a separate issue, but it looks like there's a suggestion above about how that might be possible to do with Github Actions.

Libation is amazing, and I'd love for more people to be able to use it! Having a signed (or even unsigned) app bundle would make this something I could recommend to my other mac-using friends to use. Many of them are not technical at all, and wouldn't feel comfortable running terminal commands to get the program set up and running.

[rmcrackan]

@timdmackey Great find -- thanks! I understand about the terminal aspect. The platform specific bits for mac and linux are difficult. If you or anyone you know is a mac developer, we welcome improvement submissions. Github has a walk-through for how to contribute.

@Mbucari In case this didn't already come up during your avalonia research, I'm tagging you here.

[Mbucari]

@timdmackey I've tried to make an app package in the past, ~~but I've been unable to solve the issue of the icns not displaying. It's maddening. At this point the only explanation I have is that macOS won't display icons for unsigned packages, but I haven't found any documentation supporting that hypothesis.~~

That said, the package does work. In fact, I added a couple of permissions to the plist and now it runs without me disabling gatekeeper or adding an exception for Libation. This confuses me, because I thought that shouldn't be possible. I rolled back my VM to right after I installed guest additions (before I had ever run Libation on it), and the app package still executed without bugging me for permissions. IDK what's going on.

Anyway...

~~Here's my work-in-progress package~~. Please download and try it. You'll need to download the most recent Libation chardonnay release and extract the program files into Contents/MacOS. Then just double-click the package and let me know what happens!

EDIT* Found the icon display problem! I had an error in my plist. Here's the new work-in-progress.

[Mbucari]

@timdmackey

OK, I've managed to put together a macos app bundle.

https://github.com/Mbucari/Libation/suites/10926896121/artifacts/552533482

You still have to --master-disable gatekeeper, but it's a self-contained bundle. Also I noticed that mp3 conversion was never working on mac. I added new .dylib files to support that feature.

The problem I see with the app bundle is that Libation is actually 3 programs: Libation, LibationCli, and Hangover. I think Hangover could be converted to a plugin within the Libation bundle, but I don't know what to do about CLI.

Calling all mac people: @timdmackey , @hutattedonmyarm, @CryptoJones

Can you offer any suggestions for bundling Hangover and LibationCli into a single App bundle? All three programs share >95% of the program files, so splitting them into three separate bundles would nearly 3x the distribution size.

@hutattedonmyarm You mentioned you have an M1 mac. I'd never thought about it before today, but we've only ever built Libation for macos x64. Would you care to test an arm64 version? Also, do you think I could get you to compile a couple of C libraries on your machine for me?

[hutattedonmyarm]

@Mbucari I think it's perfectly reasonable to have LibationCLI and Hangover both sit in Libation.app/Contents/MacOS/, I've seen a few apps doing this.

Libation works perfectly fine when I built it for M1. However I couldn't find a good way to create a universal binary (including both arm64 and x64). We can just mash both together using lipo, but that creates an enormous binary. So releasing them seperately is probably better.

I also tested your bundle creation with M1, works without modification if fed the appropriate build output. All I needed to do was to change the appropriate publishing profiles to say <RuntimeIdentifier>osx-arm64</RuntimeIdentifier>

Also, do you think I could get you to compile a couple of C libraries on your machine for me?

Sure thing!

[Mbucari]

@hutattedonmyarm

Sure thing!

Thanks!

The first one is a lib called ffmpegaac. Here's the source and build script.

To build it, you'll homebrew installed and you'll need to download this FFmpeg source package.

Here's the build command:

./build_ffmpegaac_homebrew.sh ffmpeg-5.1.2.tar.xz

The second library is libmp3lame. You'll need the build script from my repo and this LAME source package.

Here's the build command:

./build_libmp3lame_homebrew.sh lame-3.100.tar.gz arm64

NOTE: if you download the source packages through safari and it extracts the .tar.gz to .tar, the script won't work.

To test that the built libraries are working:

1. Rename ffmpegaac.dylib to ffmpegaac.arm64.dylib and place it into the bundle's MacOS folder.
2. Rename libmp3lame.dylib to libmp3lame.arm64.dylib and place it into the bundle's MacOS folder.
3. Run Libation and change the settings to download as MP3.
4. Try to download a book.

[hutattedonmyarm]

I had to use arm-apple-darwin instead of arm64 to build LAME, because:

Configuring LAME
checking build system type... arm-apple-darwin22.2.0
checking host system type... Invalid configuration `arm64': machine `arm64' not recognized
configure: error: /bin/sh ./config.sub arm64 failed

but that fails as well:

libtool: link: gcc -dynamiclib  -o .libs/libmp3lame.0.dylib  .libs/VbrTag.o .libs/bitstream.o .libs/encoder.o .libs/fft.o .libs/gain_analysis.o .libs/id3tag.o .libs/lame.o .libs/newmdct.o .libs/presets.o .libs/psymodel.o .libs/quantize.o .libs/quantize_pvt.o .libs/reservoir.o .libs/set_get.o .libs/tables.o .libs/takehiro.o .libs/util.o .libs/vbrquantize.o .libs/version.o .libs/mpglib_interface.o   -lm  -O3   -install_name  /usr/local/lib/libmp3lame.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libmp3lame-symbols.expsym
Undefined symbols for architecture arm64:
  "_hip_decode", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode1", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode1_headers", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode1_headersB", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode_exit", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode_headers", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_decode_init", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_set_debugf", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_set_errorf", referenced from:
     -exported_symbol[s_list] command line option
  "_hip_set_msgf", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode1", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode1_headers", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode1_headersB", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode_exit", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode_headers", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_decode_init", referenced from:
     -exported_symbol[s_list] command line option
  "_lame_init_old", referenced from:
     -exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libmp3lame.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I'll try to get it up later today when I have more time on my hands

[hutattedonmyarm]

Can't get LAME to build. Statically linked (--enable-shared=no as additional parameter to configure) is no problem, but can't figure out the magic to build dylibs

[Mbucari]

can't figure out the magic to build dylibs

I found that I couldn't get lame to make a dynlib, but I could make it myself after it had compiled its static libmp3lame.a (located at ./libmp3lame/.libs/libmp3lame.a) by executing gcc -dynamiclib -shared -fPIC -Wl,-v,-force_load libmp3lame.a -o libmp3lame.dylib

[hutattedonmyarm]

can't figure out the magic to build dylibs

I found that I couldn't get lame to make a dynlib, but I could make it myself after it had compiled its static libmp3lame.a (located at ./libmp3lame/.libs/libmp3lame.a) by executing gcc -dynamiclib -shared -fPIC -Wl,-v,-force_load libmp3lame.a -o libmp3lame.dylib

That worked! Downloading and MP3 conversion, working as well. I've forked and created a realease to attach the binaries. The binary is huge, but shrinks to the size of the Windows and Linux releases when I enable trimming. Was having issues with that though, so I'm keeping it disabled for now. Could be an error on my part, I'll check again tomorrow

[Mbucari]

That worked! Downloading and MP3 conversion, working as well.

Woohoo!

The binary is huge

I guess that's arm for you. Trade file size for simpler, fixed width instructions.

I've forked and created a realease

FYI, this goes with my audio library project AAXClean.Codecs

Thank you again!

EDIT* btw, did my build_ffmpegaac_homebrew.sh script work out of the box? Lame obviously didn't, but now that it's compiled we'll never need to worry about building it again (it's a dead project). But ffmpegaac may need to change in the future, so I'd like to make that process as painless as possible for any volunteer who offers to compile it for me lol.

[rmcrackan]

@Mbucari sounds like you've completed even more of this list! Again -- very impressed by the xplat progress

[hutattedonmyarm]

did my build_ffmpegaac_homebrew.sh script work out of the box?

yep!

[Mbucari]

@hutattedonmyarm We just released a Mac arm64 build. Let me know what you think!

[hutattedonmyarm]

@hutattedonmyarm We just released a Mac arm64 build. Let me know what you think!

❯ sudo spctl --master-disable && sudo spctl --add --label "Libation" /Applications/Libation.app && open /Applications/Libation.app && sudo spctl --master-enable
Password:
The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600001ff5fb0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

I'll have to look into that!

[Mbucari]

Did you move Libation.app to /Applications?

[hutattedonmyarm]

Yep. I just build it again using your current master on my machine. Everything seems fine with the exception of the Libation, LibationCli, and Hangover executables. Mine are slightly larger (148KB instead of your 129KB) for each.

Looking at the Mach-O binary headers reveals:

❯ otool -h /Applications/Libation.app/Contents/MacOS/Hangover
/Applications/Libation.app/Contents/MacOS/Hangover:
Mach header
      magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777228          0  0x00           2    17       2056 0x00a18085

❯ otool -h ~/Dev/Libation/Source/bin/Publish/MacOS-chardonnay/Hangover
/Users/max/Dev/Libation/Source/bin/Publish/MacOS-chardonnay/Hangover:
Mach header
      magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777228          0  0x00           2    18       2072 0x00a18085

There's an additional load command in mine. And otool -l reveals a nearly identical binary, except that this is present in mine and missing from the release:

Load command 17
      cmd LC_CODE_SIGNATURE
  cmdsize 16
  dataoff 128912
 datasize 19296

codesign confirms this:

❯ codesign -d /Applications/Libation.app/Contents/MacOS/Hangover
/Applications/Libation.app/Contents/MacOS/Hangover: code object is not signed at all

❯ codesign -d ~/Dev/Libation/Source/bin/Publish/MacOS-chardonnay/Hangover
Executable=/Users/max/Dev/Libation/Source/bin/Publish/MacOS-chardonnay/Hangover

Manually signing the executable with codesign -s - /Applications/Libation.app/Contents/MacOS/Hangover works.

This Apple developer forum post is the only thing I found. Looksl ike you need to code sign when you want to run an ARM binary.

[Mbucari]

@hutattedonmyarm does this command work for all three apps?

codesign --force --deep -s - /Applications/Libation.app

Also, does macOS usually come with codesign preinstalled, or do users need to install xcode to get it?

[hutattedonmyarm]

@Mbucari The command works for all of them!

I’m not sure if it’s preinstalled. I think it is, but I’ve stumbled upon some note that it is part of the Command Line Utilities for Xcode (which needs to be installed). In any case it does require an Apple developer certificate (the free one is enough).

Here’s some more info: https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS

I can try to get a GitHub workflow running with my own certificate, but I’m fairly short on time this week

[Mbucari]

@hutattedonmyarm

I just restored my macOS Monterey VM to a fresh installation, and the codesign tool is installed.

I'm still a bit confused about the arm64 requirements.

• Am I correct that the codesign -s - command merely creates the placeholders in the executable files/package for the signature, but does not actually sign the files/package?
• On a fresh install install of macOS on apple silicon, is executing the codesign --force --deep -s - /Applications/Libation.app command sufficient for users to run Libation?
• Do apple silicon users still need to add a gatekeeper exception?

I can try to get a GitHub workflow running with my own certificate, but I’m fairly short on time this week

That would be great! I just tried changing the linux workflow to runs-on: macos-latest in hopes that we'd get lucky and everything would just work, but it failed on the first step because macos grep doesn't support the -P switch 😂

[hutattedonmyarm]

I'm still a bit confused about the arm64 requirements.

• Am I correct that the codesign -s - command merely creates the placeholders in the executable files/package for the signature, but does not actually sign the files/package?

Sort of, yes. The - creates an ad-hoc signature (instead of using a real one), which just adds the hash and no cryptographic proof.

• On a fresh install install of macOS on apple silicon, is executing the codesign --force --deep -s - /Applications/Libation.app command sufficient for users to run Libation?
• Do apple silicon users still need to add a gatekeeper exception?

codesign --force --deep -s - /Applications/Libation.app in addition to the gatekeeper exception might just as well work. I tried remove the gatekeeper exception but that didn't work ("error: no matches for search or update operation" whatever) so I can't really test it. Ideal would probaby to add the codesigning step to the workflow and have users just add the gatekeeper exception. Not sure if it works though

[Mbucari]

Ideal would probaby to add the codesigning step to the workflow and have users just add the gatekeeper exception.

I agree, and I think the only way to do that is to build Libation on the macos runner. I tried using zsign on linux, but it just did not work.

So yeah, we need to port the build-linux.yml workflow and the associated scripts to macos and just build both linux and mac releases on macos runners.

[hutattedonmyarm]

@Mbucari I think I got it! I made two different versions: The first one just ports the build-linux.yml to run on macOS. THe second one runs the linux build on Ubuntu and macOS buils on macOS. Mainly, because I had to wait over an hour for a macOS runner to become available during testing. I don't know if that's a common occurance or I got unlucky.

Anyways, tag v9.3.4.a builds everything on macOS and tag v9.3.4.b uses Ubuntu for the linux builds.

The difference to the original isn't big, I had to get creative without grep's -P flag and macOS uses zsh by default which can't to a "lowercase only the first letter". Other than that, only an install of dpkg was necessary to bundle the linux package.

The second one is a bit more fiddly, because I need to specify matrix.os: [ubuntu-latest, macos-latest] so that it matches a runs-on specification. I needed to update how the OS name is generated to provide the correct publishing profile.

By the looks of it, this should run fine on a vanilla macOS, but I haven't tested that

[rmcrackan]

Wow, this list looks nearly complete. Ambitious!

[Mbucari]

@rmcrackan I just got a free license for JetBrains Rider via their open source dev program, and it actually works in the macOS VM (unlike VSCode which had graphical issues due to VM drivers). The x-plat future is looking brighter than ever!

[rmcrackan]

Very cool! I didn't even know that initiative existed.

[rmcrackan]

Is Linux arm64 still a goal? Or is this list all done?