Mac OS 10.6, libc++.from.MP.10.6.mac64.zip missing entry point ___emutls_get_address in libc++.1.dylib

smith-48116 commented 2 months ago

If I use the Mac Ports libcxx then Arctic-Fox works as expected. The files in the .zip file file 'libc++.from.MP.10.6.mac64.zip' on this github project do not work.

I wanted to install Artic-Fox on machines that did not have XCode or Mac Ports. I tried using the .dylib files in libc++.from.MP.10.6.mac64.zip and moved them to /usr/lib. When launching Arctic-Fox it error'd out.

Doing a file compare I found these two files differ from what Mac Ports installs.

diff /usr/lib/libc++.dylib "/Users/hsmith/Downloads/libc++.from.MP.10.6.mac64.zip/libc++.dylib" diff /usr/lib/libc++abi.dylib "/Users/hsmith/Downloads/libc++.from.MP.10.6.mac64.zip/libc++abi.dylib"

The complete error report from MacOS is attached.

Port libcxx @5.0.1_5+emulated_tls+universal contains: /opt/local/var/system_roots/libcxx-5.0.1-5.tgz

Date/Time: 2024-08-17 08:50:52.915 -0400 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6

Interval Since Last Report: 20500 sec Crashes Since Last Report: 16 Per-App Crashes Since Last Report: 7 Anonymous UUID: 0580E17A-54E2-4D6D-8D37-8699D0BEDBFD

Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Dyld Error Message: Symbol not found: ___emutls_get_address Referenced from: /Volumes/Arctic Fox/ArcticFox.app/Contents/MacOS/XUL Expected in: /usr/lib/libc++.1.dylib Errors.txt

rmottola commented 2 months ago

This looks strange, since I packed files from the system where I compiled. Looks like a different TLS setting. Will check.

smith-48116 commented 2 months ago

Did you have a chance to look at this yet? I have a MacOS 10.6 machine that I am trying to connect to a Synology (DSM 7.2) via HTTP and I was thinking that this issue may have been the problem. Thanks.

rmottola commented 2 months ago

@smith-48116 I just did an upgrade and checked on my only 10.6 64bit system (so no chance of error) and the files are unchanged. I did not pack the whole libcxx directory, I could zip it as a whole for you. Do you have macports on that system?

I wonder:

you might have some other library that causes conflict
we are missing some other library instead, even if there is no direct error

smith-48116 commented 2 months ago

Something may be missing. The Mac Ports versions of the DLLs fix the crash on start error so I ran with those.

I tried Artic-Fox on a MacOS 10.5.8 machine and a MacOS 10.6 machine, both were unable to communicate via HTTP to the Synology DSM 7.2. It could see the unit, DSM was in the Window title, but the page is blank. Neither machine has ever had XCode, Fink, or Mac Ports installed on them. These are running on 2009 era Mac Pros (Intel).

I can run Artic-Fox against a Synology DSM 6.2 setup from these versions of the MacOS running in WMWare Workstation 15 without issue.

The Synology DSM uses Javascript. I suspect that the problem may be how Synology DSM 7.2 has a higher requirement for Javascript where the older Synology DSM 6.1 may have supported earlier versions. I have tried every experiment to debug that I could think of but I could not solve the problem.

Interestingly, I tried TenFour with the same results. A blank page is shown. Synology says on their webpage only to use a 'modern browser'.

6.2 Browser Support:

https://www.synology.com/en-us/dsm/6.2/software_spec/dsm

7.2 Browser Support:

https://www.synology.com/en-us/dsm/7.2/software_spec/dsm

There are no details given about things like Javascript requirements.

On Tue, Aug 27, 2024 at 7:49 AM Riccardo @.***> wrote:

@smith-48116 https://github.com/smith-48116 I just did an upgrade and checked on my only 10.6 64bit system (so no chance of error) and the files are unchanged. I did not pack the whole libcxx directory, I could zip it as a whole for you.

I wonder:

you might have some other library that causes conflict

we are missing some other library instead, even if there is no direct error

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2312346200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3SUY3TCJCW7CIT7UWLZTRRUFAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGM2DMMRQGA . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

@smith-48116 I do not supply a working AF for 10.5, I can build it but it does not run, there is a branch, if you are interested. I don't know what JS version is needed. Most probably 7.2 Synology raised JS needs, I don't know, but in case better a separate report for version support. Please let's concentrate on the libc++ problem first.

Sum up: on a clean machine without MacPorts/Fink/HomeBrew you need libraries. Which versions do you used? please use v45 now. If you use those supplied by me, AF doesn't start because of emuTLS symbols, if you use some of yours (gotten from where?) it does work? Where do you get yours? Mine are from MacPorts /opt/local/lib/libcxx

To be on the safe side, I zipped right now the whole dire content again and added it to the v45 resources, if you care to try.

smith-48116 commented 2 months ago

Correct, the version you are distributing off github crashes on 10.5 and 10.6.

Yes, my version is from Mac Ports. I had previously installed libcxx for a different purpose.

I simply used the version from Mac Posts on a virgin machine and it was successful (no crash on start).

The Mac Ports version of the libc++ .dylib files, 10.5 and 10.6, Artic-Fox runs fine.

I have uploaded a copy of the .dylibs that I installed from Mac Ports. This is on my Google Drive:

https://drive.google.com/file/d/1ey_qdnu3rYd_cgY5C0X_Xk3N0x4MjCXL/view?usp=sharing

On Tue, Aug 27, 2024 at 9:41 AM Riccardo @.***> wrote:

@smith-48116 https://github.com/smith-48116 I do not supply a working AF for 10.5, I can build it but it does not run, there is a branch, if you are interested. I don't know what JS version is needed. Most probably 7.2 Synology raised JS needs, I don't know, but in case better a separate report for version support. Please let's concentrate on the libc++ problem first.

Sum up: on a clean machine without MacPorts/Fink/HomeBrew you need libraries. If you use those supplied by me, AF doesn't start because of emuTLS symbols, if you use some of yours (gotten from where?) it does work? Where do you get yours? Mine are from MacPorts /opt/local/lib/libcxx

To be on the safe side, I zipped right now the whole dire content again and added it to the v45 resources, if you care to try.

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2312598872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3TET2IHP2I2Z3ZH6TTZTR6YTAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGU4TQOBXGI . You are receiving this because you were mentioned.Message ID: @.***>

smith-48116 commented 2 months ago

I have made a misstatement, I was not running Artic-Fox on 10.5. I was running TenFour on 10.5.

I am running Artic-Fox on 10.6 only.

rmottola commented 2 months ago

@smith-48116 would you mind testing v45 and the dylibs I provided with v45? they came from the same system. Also maybe v45 helps your problem, it has JS improvements.

smith-48116 commented 2 months ago

I was running 45 on the virgin setup (No Mac Ports, No Fink). Stock MacOS 10.6.8. That is where the initial crash report came from.

I can do testing after hours, it is an back-office computer under use all day from 8am EST to 6pm EST on a real machine.

Alternatively, I could set up another WMWare test environment but that will take a few minutes.

If you have something to test I can do that.

From the first post (with attached Errors.txt file).

Date/Time: 2024-08-17 08:50:52.915 -0400 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6

....

Binary Images: ... 0x17c26e000 - 0x17c271fff +org.mozilla.arctic fox 45.0 (4524.8.9) <81D747BA-805C-3C2E-ABB4-75733816C681> /Volumes/Arctic Fox/ArcticFox.app/Contents/MacOS/arcticfox

On Tue, Aug 27, 2024 at 11:45 AM Riccardo @.***> wrote:

@smith-48116 https://github.com/smith-48116 would you mind testing v45 and the dylibs I provided with v45? they came from the same system. Also maybe v45 helps your problem, it has JS improvements.

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2312921943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3VGHB3FYAJXRGZCHBDZTSNLDAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSHEZDCOJUGM . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

I was running 45 on the virgin setup (No Mac Ports, No Fink). Stock MacOS 10.6.8. That is where the initial crash report came from. I can do testing after hours, it is an back-office computer under use all day from 8am EST to 6pm EST on a real machine. Alternatively, I could set up another WMWare test environment but that will take a few minutes. If you have something to test I can do that.

I added a complete archive of libcxx to try.

If you could tell me from which path you got your MacPort libraries that made it work... maybe I am zipping the wrong dir? Strange because it used to work for others.

smith-48116 commented 2 months ago

port installed libcxx

The following ports are currently installed: libcxx @5.0.1_5+emulated_tls+universal (active)

On Tue, Aug 27, 2024 at 5:12 PM Riccardo @.***> wrote:

I was running 45 on the virgin setup (No Mac Ports, No Fink). Stock MacOS 10.6.8. That is where the initial crash report came from. I can do testing after hours, it is an back-office computer under use all day from 8am EST to 6pm EST on a real machine. Alternatively, I could set up another WMWare test environment but that will take a few minutes. If you have something to test I can do that.

I added a complete archive of libcxx to try.

If you could tell me from which path you got your MacPort libraries that made it work... maybe I am zipping the wrong dir? Strange because it used to work for others.

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2313565277, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3TQEG4YK63Y7LODOHTZTTTUVAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGU3DKMRXG4 . You are receiving this because you were mentioned.Message ID: @.***>

smith-48116 commented 2 months ago

All libc++ files on drive:

/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.1.dylib /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.dylib /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++abi.dylib /Users/hsmith/Downloads/libc++.from.MP.10.6.mac64 /usr/lib/libc++.1.0.dylib /usr/lib/libc++.1.dylib /usr/lib/libc++.dylib /usr/lib/libc++abi.1.0.dylib /usr/lib/libc++abi.1.dylib /usr/lib/libc++abi.dylib

On Tue, Aug 27, 2024 at 5:28 PM Heath Smith @.***> wrote:

port installed libcxx

The following ports are currently installed: libcxx @5.0.1_5+emulated_tls+universal (active)

On Tue, Aug 27, 2024 at 5:12 PM Riccardo @.***> wrote:

I was running 45 on the virgin setup (No Mac Ports, No Fink). Stock MacOS 10.6.8. That is where the initial crash report came from. I can do testing after hours, it is an back-office computer under use all day from 8am EST to 6pm EST on a real machine. Alternatively, I could set up another WMWare test environment but that will take a few minutes. If you have something to test I can do that.

I added a complete archive of libcxx to try.

If you could tell me from which path you got your MacPort libraries that made it work... maybe I am zipping the wrong dir? Strange because it used to work for others.

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2313565277, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3TQEG4YK63Y7LODOHTZTTTUVAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGU3DKMRXG4 . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

Pretty similar: libcxx @5.0.1_5+emulated_tls+universal (active)

a search for libc++.dylib:

./Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.dylib
./opt/local/lib/libcxx/libc++.dylib
./opt/local/libexec/llvm-11/lib/libc++.dylib
./Users/multix/libc++ from MP 10.6 mac64/libc++.dylib
./usr/lib/libc++.dylib

there is llmvm-11 lib, but I compile with clang6

smith-48116 commented 2 months ago

This is the location of the Mac Ports package: /opt/local/var/system_roots/libcxx-5.0.1-5.tgz

Unpacking:

sudo tar -xvzf /opt/local/var/system_roots/libcxx-5.0.1-5.tgz -C /opt/local/lib/

otool -L libc++.1.dylib

libc++.1.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++.dylib

libc++.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++abi.dylib

libc++abi.dylib: /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

I have placed the DLLs here:

https://drive.google.com/file/d/1SVOwMi5MAP7LHJlgiTLTr_aRvxf_1DjE/view?usp=drive_link

libcxx @5.0.1_5+emulated_tls+universal (active)

Perhaps the difference is that this library from Mac Ports is using emulated_tls whereas the .dylibs you are sending out are not built for emulated thread local storage.

--- Mac ports installed this version of the libcxx library. libcxx @5.0.1_5+emulated_tls+universal (active) What is the emulated_tls? ChatGPT said:

The +emulated_tls variant in the MacPorts installation of libcxx indicates that this version of the libcxx library has been built with support for emulated thread-local storage (TLS). What Does +emulated_tls Mean?

When you see +emulated_tls in the context of MacPorts and libcxx, it means that the library has been compiled with a feature to emulate thread-local storage. This is particularly useful on systems that do not natively support TLS or have limited support for it. Why is emulated_tls Important?

On older systems, such as macOS 10.6, which you are using, native support for thread-local storage via the __thread or thread_local keywords might not be fully available or reliable. Emulated TLS is a workaround that allows applications and libraries requiring thread-local variables to still function correctly by emulating this feature in software. Implications of Using libcxx with +emulated_tls

Compatibility: This version of libcxx is more compatible with older systems because it doesn't rely on native TLS support, which might be absent or incomplete.
Performance: Emulated TLS can be slower than native TLS because it involves extra overhead to manage thread-local variables in software rather than relying on direct support from the hardware or OS.
Stability: Ensuring compatibility with systems that do not fully support native TLS can prevent crashes or undefined behavior, such as the one you encountered with the missing ___emutls_get_address symbol.

Summary

The +emulated_tls variant in your installed libcxx library means that the library is built to use software emulation for thread-local storage, ensuring that it works on older systems like macOS 10.6. This is likely why you encountered a missing ___emutls_get_address symbol—your application or one of its dependencies is expecting this emulation support, which this version of libcxx provides.

--- What is emutls? About the original reported error:Dyld Error Message: Symbol not found: ___emutls_get_address Referenced from: /Volumes/Arctic Fox/ArcticFox.app/Contents/MacOS/XUL Expected in: /usr/lib/libc++.1.dylib

See Error file:Errors.txt https://github.com/user-attachments/files/16645107/Errors.txt ChatGPT said:

emutls stands for "emulated thread-local storage". It is a mechanism used by certain compilers, most notably the GNU Compiler Collection (GCC), to provide support for thread-local variables on systems that do not natively support the __thread or thread_local keyword in C/C++. Thread-Local Storage (TLS)

Thread-local storage is a way of defining variables that are unique to each thread. Each thread has its own separate instance of these variables, so changes made by one thread do not affect the variables in other threads. Emulated Thread-Local Storage (emutls)

Some older systems, or those with compilers that do not fully support native thread-local storage, may require emulation. In such cases, emutls is used. When thread-local storage is not natively supported, the compiler generates calls to helper functions (like _emutls_getaddress) to manage thread-local variables manually. The Missing Symbol in Your Error (emutls_get_address)

The specific symbol ___emutls_get_address refers to a function generated by the compiler that is part of this emulation process. It’s used to retrieve the correct instance of a thread-local variable for the current thread. Why the Error Occurs

The error in your crash log indicates that the application is looking for this function in the libc++.1.dylib library, but it is not present. This can happen if:

The application was compiled with a version of a compiler that uses emutls, but the runtime environment does not have the corresponding support library.
The version of libc++.1.dylib being used does not include this emulated TLS support.

Solutions

Update Libraries: Ensure that the correct version of libc++.1.dylib or other supporting libraries is available.
Check Compiler Options: If you are compiling the application yourself, ensure you are using a compiler and runtime that are consistent and support the required thread-local storage mechanism.
Use Alternative Libraries: If possible, link against a different version of the C++ standard library that includes the needed emutls support.

On Wed, Aug 28, 2024 at 2:06 AM Riccardo @.***> wrote:

Pretty similar: libcxx @5.0.1_5+emulated_tls+universal (active)

a search for libc++.dylib:

./Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.dylib ./opt/local/lib/libcxx/libc++.dylib ./opt/local/libexec/llvm-11/lib/libc++.dylib ./Users/multix/libc++ from MP 10.6 mac64/libc++.dylib ./usr/lib/libc++.dylib

there is llmvm-11 lib, but I compile with clang6

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2314391574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3WTOBPTJCULEBWA3OLZTVSGJAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJUGM4TCNJXGQ . You are receiving this because you were mentioned.Message ID: @.***>

smith-48116 commented 2 months ago

The package from Mac Ports contains the exact same versions as the XCode (3.26) SDK.

cd /Developer/SDKs/MacOSX10.6.sdk/usr/lib/

ls libc++*

libc++.1.dylib libc++.dylib libc++abi.dylib

otool -L libc++.1.dylib

libc++.1.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++.dylib

libc++.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++.1.dylib

libc++.1.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

On Wed, Aug 28, 2024 at 6:43 AM Heath Smith @.***> wrote:

This is the location of the Mac Ports package: /opt/local/var/system_roots/libcxx-5.0.1-5.tgz

Unpacking:

sudo tar -xvzf /opt/local/var/system_roots/libcxx-5.0.1-5.tgz -C /opt/local/lib/

otool -L libc++.1.dylib

libc++.1.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++.dylib

libc++.dylib: /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

otool -L libc++abi.dylib

libc++abi.dylib: /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 5.0.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

I have placed the DLLs here:

https://drive.google.com/file/d/1SVOwMi5MAP7LHJlgiTLTr_aRvxf_1DjE/view?usp=drive_link

libcxx @5.0.1_5+emulated_tls+universal (active)

Perhaps the difference is that this library from Mac Ports is using emulated_tls whereas the .dylibs you are sending out are not built for emulated thread local storage.

--- Mac ports installed this version of the libcxx library. libcxx @5.0.1_5+emulated_tls+universal (active) What is the emulated_tls? ChatGPT said:

The +emulated_tls variant in the MacPorts installation of libcxx indicates that this version of the libcxx library has been built with support for emulated thread-local storage (TLS). What Does +emulated_tls Mean?

When you see +emulated_tls in the context of MacPorts and libcxx, it means that the library has been compiled with a feature to emulate thread-local storage. This is particularly useful on systems that do not natively support TLS or have limited support for it. Why is emulated_tls Important?

On older systems, such as macOS 10.6, which you are using, native support for thread-local storage via the __thread or thread_local keywords might not be fully available or reliable. Emulated TLS is a workaround that allows applications and libraries requiring thread-local variables to still function correctly by emulating this feature in software. Implications of Using libcxx with +emulated_tls

Compatibility: This version of libcxx is more compatible with older systems because it doesn't rely on native TLS support, which might be absent or incomplete.

Performance: Emulated TLS can be slower than native TLS because it involves extra overhead to manage thread-local variables in software rather than relying on direct support from the hardware or OS.

Stability: Ensuring compatibility with systems that do not fully support native TLS can prevent crashes or undefined behavior, such as the one you encountered with the missing ___emutls_get_address symbol.

Summary

The +emulated_tls variant in your installed libcxx library means that the library is built to use software emulation for thread-local storage, ensuring that it works on older systems like macOS 10.6. This is likely why you encountered a missing ___emutls_get_address symbol—your application or one of its dependencies is expecting this emulation support, which this version of libcxx provides.

--- What is emutls? About the original reported error:Dyld Error Message: Symbol not found: ___emutls_get_address Referenced from: /Volumes/Arctic Fox/ArcticFox.app/Contents/MacOS/XUL Expected in: /usr/lib/libc++.1.dylib

See Error file:Errors.txt https://github.com/user-attachments/files/16645107/Errors.txt ChatGPT said:

emutls stands for "emulated thread-local storage". It is a mechanism used by certain compilers, most notably the GNU Compiler Collection (GCC), to provide support for thread-local variables on systems that do not natively support the __thread or thread_local keyword in C/C++. Thread-Local Storage (TLS)

Thread-local storage is a way of defining variables that are unique to each thread. Each thread has its own separate instance of these variables, so changes made by one thread do not affect the variables in other threads. Emulated Thread-Local Storage (emutls)

Some older systems, or those with compilers that do not fully support native thread-local storage, may require emulation. In such cases, emutls is used. When thread-local storage is not natively supported, the compiler generates calls to helper functions (like _emutls_getaddress) to manage thread-local variables manually. The Missing Symbol in Your Error (emutls_get_address)

The specific symbol ___emutls_get_address refers to a function generated by the compiler that is part of this emulation process. It’s used to retrieve the correct instance of a thread-local variable for the current thread. Why the Error Occurs

The error in your crash log indicates that the application is looking for this function in the libc++.1.dylib library, but it is not present. This can happen if:

The application was compiled with a version of a compiler that uses emutls, but the runtime environment does not have the corresponding support library.

The version of libc++.1.dylib being used does not include this emulated TLS support.

Solutions

Update Libraries: Ensure that the correct version of libc++.1.dylib or other supporting libraries is available.

Check Compiler Options: If you are compiling the application yourself, ensure you are using a compiler and runtime that are consistent and support the required thread-local storage mechanism.

Use Alternative Libraries: If possible, link against a different version of the C++ standard library that includes the needed emutls support.

On Wed, Aug 28, 2024 at 2:06 AM Riccardo @.***> wrote:

Pretty similar: libcxx @5.0.1_5+emulated_tls+universal (active)

a search for libc++.dylib:

./Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.dylib ./opt/local/lib/libcxx/libc++.dylib ./opt/local/libexec/llvm-11/lib/libc++.dylib ./Users/multix/libc++ from MP 10.6 mac64/libc++.dylib ./usr/lib/libc++.dylib

there is llmvm-11 lib, but I compile with clang6

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2314391574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3WTOBPTJCULEBWA3OLZTVSGJAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJUGM4TCNJXGQ . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

I tried hiding MacPorts my renaming /opt to /opt2. I confirmed that some apps like emacs stop starting. ArcticFox however still works for me. I am not able to reproduce the issues other have: the binary "just works". Perhaps because I have XCode installed?

Essentially I am unable to reproduce the problem. It just works for me without extra libraries and I packaged you "my libraries"...

smith-48116 commented 2 months ago

Perhaps. Fink and Mac Ports are also doing some magic to make their .dylib files relocateable. The DYLIBS path variable was disabled by Apple for security reasons from 10.6 forward so I am not sure how they can have their .dylib files locatable even though they are not in /usr/lib.

If you have Fink, Mac Ports, or Homebrew installed, they may have changed the OS environment so that different .dylibs are being loaded.

I do not know how they achieved this.

On Wed, Aug 28, 2024 at 10:19 AM Riccardo @.***> wrote:

I tried hiding MacPorts my renaming /opt to /opt2. I confirmed that some apps like emacs stop starting. ArcticFox however still works for me. I am not able to reproduce the issues other have: the binary "just works". Perhaps because I have XCode installed?

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2315473096, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3TUUJVQBUN3DY7Q26DZTXL7DAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJVGQ3TGMBZGY . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

I don't know... but the core is, it didn't work for you without libraries I think the MacPorts version has TLS emulation while apple's not. Did you try the "complete" lib I shared here https://github.com/rmottola/Arctic-Fox/releases/expanded_assets/v45.0 ?

For 10.7 and later, IIRC correctly from MacPorts, there is no issue with TLS emulation, although I have seen libcxx still installed.

rmottola commented 2 months ago

I cannot reproduce the issue and no confirmation was given that with the new supplied libcxx the problem persists.

On internet forum, issues are written where old libcxx, by wicknix, was used/mixed with. I don't know if this is the case, but since MacPorts use solves it, it could be a hint.

smith-48116 commented 2 months ago

I have been very busy lately. I can try it under VMware, maybe tomorrow. Can you send a link to the folder again?

On Mon, Sep 9, 2024, 5:48 PM Riccardo @.***> wrote:

I cannot reproduce the issue and no confirmation was given that with the new supplied libcxx the problem persists.

On internet forum, issues are written where old libcxx, by wicknix, was used/mixed with. I don't know if this is the case, but since MacPorts use solves it, it could be a hint.

— Reply to this email directly, view it on GitHub https://github.com/rmottola/Arctic-Fox/issues/214#issuecomment-2339213738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQSM3XPN5NMIE6NMRZQOETZVYJTDAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZZGIYTGNZTHA . You are receiving this because you were mentioned.Message ID: @.***>

rmottola commented 2 months ago

@smith-48116 no problem, I was just annotating after some research. It is in v45 assets: https://github.com/rmottola/Arctic-Fox/releases/expanded_assets/v45.0

EAZYBLACK commented 1 month ago

i have same issue

rmottola commented 1 month ago

@EAZYBLACK is it really the same issue, error about ___emutls_get_address and not a similar libc++ error? In case do you confirm you are installing the libc++ version supplied with ArcticFox 45 and not previous ones by wicknix? As alternative you can install/use a recent version of MacPorts.

EAZYBLACK commented 1 month ago

@EAZYBLACK is it really the same issue, error about ___emutls_get_address and not a similar libc++ error? In case do you confirm you are installing the libc++ version supplied with ArcticFox 45 and not previous ones by wicknix? As alternative you can install/use a recent version of MacPorts.

exactly same, using arcticfox 45 libc++ errors but using those ones that he sent work fine

rmottola commented 1 month ago

@smith-48116 @EAZYBLACK I think I finally understood the issue, thanks to Ken. MacPorts on 10.6 installs two libcxx versions and I was sharing the wrong one, since I build with "only" clang 6.0

I just released 45.1 and in the assets there is a new libcxx file. Please remove the old one (this one contains less files) let me know.

rmottola commented 1 month ago

any news, @smith-48116 @EAZYBLACK ?

rmottola / Arctic-Fox

Mac OS 10.6, libc++.from.MP.10.6.mac64.zip missing entry point ___emutls_get_address in libc++.1.dylib #214