Mac OS 10.6, libc++.from.MP.10.6.mac64.zip missing entry point ___emutls_get_address in libc++.1.dylib #214
Comments
|
This looks strange, since I packed files from the system where I compiled. Looks like a different TLS setting. Will check. |
|
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. |
|
@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:
|
|
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:
1. you might have some other library that causes conflict
2. we are missing some other library instead, even if there is no
direct error
—
Reply to this email directly, view it on GitHub
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3SUY3TCJCW7CIT7UWLZTRRUFAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGM2DMMRQGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@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. Sum up: on a clean machine without MacPorts/Fink/HomeBrew you need libraries. Which versions do you used? please use v45 now. 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. |
|
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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3TET2IHP2I2Z3ZH6TTZTR6YTAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGU4TQOBXGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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.
|
|
@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. |
|
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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3VGHB3FYAJXRGZCHBDZTSNLDAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSHEZDCOJUGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
|
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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3TQEG4YK63Y7LODOHTZTTTUVAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGU3DKMRXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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
> <#214 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AOQSM3TQEG4YK63Y7LODOHTZTTTUVAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGU3DKMRXG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Pretty similar: a search for libc++.dylib: there is llmvm-11 lib, but I compile with clang6 |
|
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_get_address) 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:
1. The application was compiled with a version of a compiler that uses
emutls, *but the runtime environment does not have the corresponding
support library*.
2. 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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3WTOBPTJCULEBWA3OLZTVSGJAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJUGM4TCNJXGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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_get_address) 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:
1. The application was compiled with a version of a compiler that uses
emutls, *but the runtime environment does not have the corresponding
support library*.
2. 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
> <#214 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AOQSM3WTOBPTJCULEBWA3OLZTVSGJAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJUGM4TCNJXGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
I tried hiding MacPorts my renaming /opt to /opt2. Essentially I am unable to reproduce the problem. It just works for me without extra libraries and I packaged you "my libraries"... |
|
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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3TUUJVQBUN3DY7Q26DZTXL7DAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJVGQ3TGMBZGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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. For 10.7 and later, IIRC correctly from MacPorts, there is no issue with TLS emulation, although I have seen libcxx still installed. |
|
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. |
|
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
<#214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQSM3XPN5NMIE6NMRZQOETZVYJTDAVCNFSM6AAAAABMVOCWQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZZGIYTGNZTHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@smith-48116 no problem, I was just annotating after some research. |
|
i have same issue |
|
@EAZYBLACK is it really the same issue, error about ___emutls_get_address and not a similar libc++ error? |
exactly same, using arcticfox 45 libc++ errors but using those ones that he sent work fine |
|
@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. |
|
any news, @smith-48116 @EAZYBLACK ? |
|
oh sorry for late reply, i will try it later and tell |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: