-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not build on CURRENT #1
Comments
The error is due to a (relatively) recently introduced sanity check, see https://reviews.llvm.org/D45845. At the moment I have no idea how to work around that. |
Can you give an overview how things work? Maybe I can come up with something. |
What am I doing with symver directives in the first place? They are used to export Why multiple versions? Glibc might have multiple different implementations of something, but we, obviously, do not. So, it's kinda makes sense to export some symbols multiple times. |
For example:
|
So, this shim is used to fulfill the dependency on Linux libc? Ot intercepts calls to Linux libc functions and re-route them to FreeBSD ones? |
Yeah, the "nv" part in the name is a bit of misnomer. It's rather a reasonably generic, albeit very incomplete, glibc shim with Nvidia specific run & setup scripts.
There is no interception per se. If you export symbols as described above (that is, no defaults), rtld will happily route everything for you. It's really simple. Almost unbelievably so. |
I see, thanks. But is that safe? I bet, many FreeBSD libc functions operate differently that Linux ones. This might cause problems, no? |
Other than the bugs in the implementation itself (there are plenty of those, of course), this should be reasonably safe as long as the loaded Linux libraries:
So, proceed with caution. |
If GAS doesn't support multiple |
Hmm… Glibc seems to use |
Ok, try the latest commit.
I rechecked that part, turns out default versions do not matter either way, I just dislike them for some reason I can't remember :/ |
Yep, it builds! I had to remove all mentions of Now, I'm trying to use
Added path to
The error message looks strange. Any idea what does it mean? |
You'll probably want to know that for CUDA there are some blocking issues on the kernel driver side.
You are setting LD_LIBRARY_PATH a bit too early and it is getting picked up by a FreeBSD executable trying to run the script itself. |
I didn't even reach that stage yet. Have you checked if things improved so far? Stupid me. Now the error is
|
They didn't.
You are not supposed to load /compat/linux/usr/lib64/librt.so.1. Unfortunately, since there is also /usr/lib/librt.so.1 I had to resort to binary patching to avoid conflicts and the corresponding LD_LIBMAP override is differently named. I admit this is a bit confusing. |
If I read it right, the problem is that
Ouch. This is too much hacks, IMO. I think, I'll try something else for my problem. |
Eh, it's a function in nvidia.ko kernel module, see nvidia/nvidia_os.c.
Not my bug, so no opinion.
Is it? In any case, the kernel part is both more important and more difficult here. It makes sense to concentrate on that. |
I see, thanks for clearing this up. Let's close this issue, as nvshim now builds on CURRENT. |
FYI, I committed a workaround for this particular annoyance in c1633b6. |
@arrowd You might be interested in shkhln/revird-aidivn@077197f. Note that this is meant to be used in combination with either a dummy nvidia-uvm kernel module or an equivalent LD_PRELOAD trick. Seems to pass a simple sanity check so far:
|
This looks promising! Unfortunately, I don't have time to look at it right now. Do you plan to upstream this patch into FreeBSD ports tree? |
I don't have the patience. Plus it's a relatively quick and dirty patch job, so it's not necessarily appropriate for submission as is. |
Что-то здесь не так. |
Does |
Yes, native |
Compiling |
As far as I understand, native FreeBSD gcc- and clang-compiled c++ libraries are pretty safe to mix. I don't see why that should be different for a Linux c++ library in principle, considering it's the same ABI.
That works. |
From my experience, it was never been like this.
... and here's another proof of that. |
The funny thing is that this working |
Ok, I didn't pay attention and passed a wrong path to ldd. It's |
Aha, the most relevant comment here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221288#c4. Looks like in practice ports are using this solution instead: https://markmail.org/message/dwgafctuoywpuhhr. Not applicable to our case, unfortunately. |
Just to clear things up - |
Specifically, libcufft.so.8.0 is a Linux binary as well as oceanFFT executable itself (I occasionally run Linux programs with the shim, it's convenient for testing). Everything else, including libstdc++, is native code. |
If the executable itself is Linux, where do FreeBSD come from? It should use everything from |
Something like |
Then how about making |
Честно говоря, я даже не понял что здесь написано. Просто замапить |
Хотя… Можно замапить |
Я понял так, что проблема здесь в том, что На |
Получается как-то так: 09fa162. |
При более внимательном рассмотрении на CXXRT_1.0 из В любом случае, с драйвером и библиотеками здесь все примерно ясно. Стоит ли делать с этим что-то дальше? Я как-то не вижу никакого интереса к CUDA со стороны FreeBSD, если честно. |
Ну тут нечего смотреть. Будет куда - будет интерес, порты появятся, юзающие ее. Но затыкать плюсовый рантайм - плохая идея, конечно. Эта |
Ммм… Я не имею в виду пользовательский интерес. Есть какие-то шансы уговорить кого-нибудь привести в нормальный вид патч для драйвера? Это прямо совсем не мой навык. (Тут еще немного замешана лицензия, которая одновременно разрешает и запрещает нам копирование кода из Линуксового драйвера. Это тоже по-своему интересно, хотя большой опасности здесь нет.)
Часть дистрибутива Куды, конечно. Идущая с драйвером |
А что за патч? Об этом речь? https://reviews.freebsd.org/D22521
Остается запускать кудышные приложения целиком в линуксе, либо собирать с |
Нет, вот этот патч: https://github.com/shkhln/revird-aidivn/compare/master...afdiuxc.patch. Он здесь уже упоминался.
Я думаю кто-нибудь соберет «правильный» libstdc++, если оно реально понадобится. Можно на это пока не обращать внимания. |
О, я его профукал. Ну, за лицензию можно не особо беспокоиться, я думаю, т.к. это патчи. Что тут за проблема может быть? Сложнее будет запинать danfe, но это я могу взять на себя.
Я в этом не уверен. Это |
Местами у Нвидии в файлы натыкан заголовок, запрещающий любое использование кода. В корне дистрибутива драйвера лежит более-менее нормальная лицензия. Насколько я понимаю, они друг друга не отменяют. Очень теоретическая проблема по большей части.
Да уж.
Я не с потолка взял эту идею, а из комментариев типа вот этого: http://lists.llvm.org/pipermail/cfe-dev/2016-August/050278.html. Цитата: «We solved this in FreeBSD by linking both libstdc++ and libc++ against libcxxrt.» Не знаю куда это решение делось. Здесь также немного про это есть: https://wiki.freebsd.org/NewC++Stack. |
I met some problems when tried building nvshim on FreeBSD CURRENT.
First of all, there is no
sys/sysinfo.h
file anymore, so I had to remove that include directive fromsrc/libc/sys/sysinfo.c
. Second, I changedclang60
toclang80
. Now I getAny idea how to fix this?
The text was updated successfully, but these errors were encountered: