Duplicate JavaNativeFoundation implementation #291
Answered
by
weisJ
hannesbraun
asked this question in
Q&A
-
|
After updating Thanks :) |
Beta Was this translation helpful? Give feedback.
Answered by
weisJ
Dec 28, 2021
Replies: 3 comments 15 replies
-
|
You are absolutely correct in the assumption that this isn’t an issue on M1 macs. This is simply due to the fact that there JavaNativeFoundation doesn’t exist in the system library path (or anywhere else for that matter). It’s certainly desirable to stop this warning on Intel macs though. I assume that the following is happening:
Now the way which is intended is that in the second step Darklaf should actually load the system version if it finds it to avoid this exact problem. I can at least guarantee that no matter which class definitions are used they are equivalent and except for the warning message no problems should occur. |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
hannesbraun
-
|
Could you please run your program with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Sure. Here you go: |
Beta Was this translation helpful? Give feedback.
15 replies
-
|
I also just checked my backups and it looks like the file was present at least until I updated to macOS 11 (Big Sur). After that, Time Machine started to exclude the system files from the backup. But I'd guess that the Edit: I checked for the existence of the |
Beta Was this translation helpful? Give feedback.
-
|
Yes indeed. This seems to be due to the fact that from macOS 11 and onwards all system libraries aren't located on disk and instead sit in the dynamic linker cache. I assume for you |
Beta Was this translation helpful? Give feedback.
-
|
I have modified the library in |
Beta Was this translation helpful? Give feedback.
-
|
Correct, Still, I makes no sense to me that the linker can't find the library provided by the system and then complains about a duplicate implementation... |
Beta Was this translation helpful? Give feedback.
-
|
I guess that once the linker sees that the library path contains rpath it doesn’t match against libraries in the cache once the rpath has been substituted. I have an idea of how to work around that but it will require some more work on the build infrastructure. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
You are absolutely correct in the assumption that this isn’t an issue on M1 macs. This is simply due to the fact that there JavaNativeFoundation doesn’t exist in the system library path (or anywhere else for that matter).
It’s certainly desirable to stop this warning on Intel macs though. I assume that the following is happening:
Now the way which is intended is that in the second step Darklaf should actually load the system version if it finds it to avoid this exact problem. I can at least guarantee that no matter which class definitions are used they are equivalent and exce…