search

webui-dev / webui

Use any web browser or WebView as GUI, with your preferred language in the backend and modern web technologies in the frontend, all in a lightweight portable library.
https://webui.me
MIT License
2.63k stars 157 forks source link

macOS - not a mach-o file #247

Closed hassandraga closed 9 months ago

hassandraga commented 9 months ago

The CI nightly build webui-macos-clang-x64 provides a corrupted .dylib file. When I compile it in my Mac, it produces a 229 Kb file. In comparison, CI produces a 202 Kb file.

I discovered that when I tried to run Python-WebUI:

examples % python3 hello_world.py  

webui_lib Exception: dlopen(/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/
site-packages/webui/webui-macos-clang-x64/webui-2.dylib, 0x0006): tried: '/Library/Frameworks/
Python.framework/Versions/3.11/lib/python3.11/site-packages/webui/
webui-macos-clang-x64/webui-2.dylib' (not a mach-o file)

@ttytm

ttytm commented 9 months ago

Hey @hassandraga,

okay let's investigate this. Unfortunately, I don't have a x64 mac for local testing.

What is the clang --version? Is it the same issue when you try to use the downloaded build with WebUI C?

ttytm commented 9 months ago

The closest indicator I have for now is V CI as it also builds examples on macOS x64. It seems to work there with the last runs.

hassandraga commented 9 months ago

clang --version

Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Is it the same issue when you try to use the downloaded build with WebUI C?

My local build works, but using the CI nightly build gives the not a mach-o file error.

ttytm commented 9 months ago

not a mach-o file is a python error afaik. Is it the same when not using the python wrapper, just the C repository?

hassandraga commented 9 months ago

just the C repository?

Good question. I test it again using the C example, and the static libwebui-2-static.a works fine. While the dynamic webui-2.dylib gives the same error as Python:

ld: warning: ignoring file webui/dist/webui-2.dylib, building for macOS-x86_64 
but attempting to link with file built for unknown-unsupported 
file format ( 0x34 0x0A 0x30 0x0A 0x34 0x30 0x39 0x36 0x0A 0x31 0x32 0x32 0x38 0x38 0x0A 0x31 )
Undefined symbols for architecture x86_64:
  "_webui_bind", referenced from:
      _main in main-036eb3.o
  "_webui_clean", referenced from:
      _main in main-036eb3.o
  "_webui_get_bool", referenced from:
      _my_function_boolean in main-036eb3.o
  "_webui_get_bool_at", referenced from:
      _my_function_boolean in main-036eb3.o
  "_webui_get_int", referenced from:
      _my_function_integer in main-036eb3.o
      _my_function_with_response in main-036eb3.o
  "_webui_get_int_at", referenced from:
      _my_function_integer in main-036eb3.o
      _my_function_with_response in main-036eb3.o
  "_webui_get_size", referenced from:
      _my_function_raw_binary in main-036eb3.o
  "_webui_get_size_at", referenced from:
      _my_function_raw_binary in main-036eb3.o
  "_webui_get_string", referenced from:
      _my_function_string in main-036eb3.o
      _my_function_raw_binary in main-036eb3.o
  "_webui_get_string_at", referenced from:
      _my_function_string in main-036eb3.o
      _my_function_raw_binary in main-036eb3.o
  "_webui_new_window", referenced from:
      _main in main-036eb3.o
  "_webui_return_int", referenced from:
      _my_function_with_response in main-036eb3.o
  "_webui_show", referenced from:
      _main in main-036eb3.o
  "_webui_wait", referenced from:
      _main in main-036eb3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [release] Error 1
ttytm commented 9 months ago

Thanks for the info @hassandraga. I'll sit with it after work today!

ttytm commented 9 months ago

229 Kb file. In comparison, CI produces a 202 Kb file.

Downloading the latest nightly macos clang x64, the dylib has 229kb. There is something different on our ends.

As a first quick attempt please try the output of this run when it's finished: https://github.com/webui-dev/webui/actions/runs/6482473891?pr=249 Maybe passing the aarch was not correctly ignored in the makefile.

Edit: The size doesn't differ in the new build action from the latest current nighlty build. Can you please re-check that it's the dylib from the nightly download that is not working?

hassandraga commented 9 months ago

I will test it tonight and back to you. Thank you 👍

hassandraga commented 9 months ago

Good job 👍 Worked for C and Python examples Also, I noticed GNUSparseFile.0 folder issue is fixed!

ttytm commented 9 months ago

Nice to hear! Gonna close the WIP PR as the latest nightly already should have the very same build file.

hassandraga commented 9 months ago

The latest nightly does not include the fix yet. Need to be updated I guess: https://github.com/webui-dev/webui/blob/main/.github/workflows/macos.yml

ttytm commented 9 months ago

The the change in the WIP PR didn't changed anything for the compilation as far as I could see. So there was no fix through the PR. That's what I ment.

ttytm commented 9 months ago

Maybe the download of the nightly file was corrupted something has gone wrong during extraction? It's the exact same file from the nightly release downloads and the build artifact in the WIP PR. Only difference is that one was packed as zip the other as tar. Can you re-test downloading the nightly to make sure?

hassandraga commented 9 months ago

The working one I download it from here: https://github.com/webui-dev/webui/actions/runs/6482473891?pr=249

The latest is not working: https://github.com/webui-dev/webui/releases/tag/nightly

ttytm commented 9 months ago

Thanks for checking 👍 then I might be wrong. Sorry about the hassle. Let's try merging it. Only other possible something is going wrong during the release deployment.

ttytm commented 9 months ago

Did it worked out, so that the builds that are pushed to the releases also work now?

hassandraga commented 9 months ago

Unfortunately not. Also the folder name GNUSparseFile.0 issue still there.

hassandraga commented 9 months ago

Work: https://github.com/webui-dev/webui/actions/runs/6482473891?pr=249

Not working: https://github.com/webui-dev/webui/releases/tag/nightly

ttytm commented 9 months ago

Okay, then the PR probably really didn't change anything but the culprit is in the release deployment.

Just to check if it's a security thing on mac, can you try to optionclick Open on the .dylib file and confirm opening it. (holding down option while clicking open is important here)

This is just to confirm the opening of the file, if a terminal opens, you can close it.

Then re-try using it.

I had such a thing once.

Also I see if I can get my hands on an old Mac from a friend for testing if fixing it seems to hard without a local reproduction.

hassandraga commented 9 months ago

I will re test it later today. However, I already see the deference in file size between the working and the not working on.

ttytm commented 9 months ago

It really is the exact same, no size changes when things are packaged.

Left the nightly release, prior to extraction, right the artifact: Screenshot_20231013_182157

Your mac might change it during extraction, maybe for security reasons, that's why I asked for the test above, if it works, probably some signing would need to be done. Or maybe something else happens during extraction that corrupts it.

ttytm commented 9 months ago

Got a mac for testing that supports catalina as max version.

On the machine I'm testing on, there is no difference in size. There is also no difference when using the archive that was used as nightly before the most recent merge.

Screenshot 2023-10-20 at 13 02 51

Also using it works - just getting an info that it was built for a newer version (12.0) than linked (10.15).

Screenshot 2023-10-20 at 13 14 38

Did something change for you? Else I think we can revert the recent changes, as the state before was less complicated. If nothing changed, maybe it's okay classifying the issue as being related to a local problem, not to the library or it's build process. If it should be investigated further, I would need a step-by-step scenario that makes the issue reproducible.

hassandraga commented 9 months ago

I have two Macs (Mini & Macbook), both don't work, but both used the same downloaded file (Nightly), and both shows 202 Kb instead of 234 Kb. Let me double check this tonight and I will back to you to confirm if the latest CI changes fixed the issue or not.

hassandraga commented 9 months ago

The non-working file is here: https://pypi.org/project/webui2/

hassandraga commented 9 months ago

I'm using the Mac Mini for development, I connected the Mini to my local network and I throw it in the basement... when I need using it, I connect to it remotely from my PC (Debian/Win11). The Macbook is not mine... I use it just for pre-release testing.

Steps:

  1. Download the nightly archive in my PC and decompress it
  2. Copying the .dylib file from my PC to Mac mini remotely
  3. Using it... fails

If I simply clone the repo directly in the Mac and build it, it will work fine. But... tonight I will try downloading the nightly build from the Mac instead of from PC.

ttytm commented 9 months ago

Yep, to isolate the bug and to narrow down the causes it would be good to start downloading on mac directly - just as you do with your test when building it. Then use it with WebUI C. If it works working up to the python lib and to downloading on other devices. Else it's impossible to tell where the cause is.

hassandraga commented 9 months ago

I test it again on macOS, a direct download from nightly build worked fine. That's mean the issue was lib get corrupted when copying it from Windows to macOS trough remote desktop control.

Thank you @ttytm, the original nightly build CI may work just fine.