You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to target NAS hardware with a dotnet5 app, which goes as low as armhf on glibc-2.13 (and pretty much all of them are gcc-4.x), even on recent NAS.
Publishing for any arm.* out of the box seems to support systems which were compiled on gcc >= 5.1 (new C++11 ABI) and have glibc >= 2.16.
I have solved the gcc part of the problem by building libstdc++.so.6 in an arm-glibc-2.13 container and just bundling it with the app+runtime (and setting LD_LIBRARY_PATH).
This appears to work on systems with glibc >= 2.16 (? only tested down to 2.17), but in my glibc-2.13 container it shows:
Failed to load /build/source-build/.dotnet/shared/Microsoft.NETCore.App/5.0.13/libcoreclr.so, error: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.16' not found (required by /build/source-build/.dotnet/shared/Microsoft.NETCore.App/5.0.13/libcoreclr.so)
I would expect to solve this if I can build libcoreclr.so on a glibc-2.13 system (container), but obviously cannot bootstrap it as ./build.sh itself throws this error since it relies on libcoreclr.so.
Does that mean I need to cross-compile (on a system which has at least glibc-2.16), and if so, is it feasible to build the rootfs for the cross-compile with glibc-2.13? Would this work, or should I expect more blockers down the line?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I want to target NAS hardware with a
dotnet5
app, which goes as low asarmhf
onglibc-2.13
(and pretty much all of them aregcc-4.x
), even on recent NAS.Publishing for any
arm.*
out of the box seems to support systems which were compiled ongcc >= 5.1
(new C++11 ABI) and haveglibc >= 2.16
.I have solved the
gcc
part of the problem by buildinglibstdc++.so.6
in anarm-glibc-2.13
container and just bundling it with the app+runtime (and settingLD_LIBRARY_PATH
).This appears to work on systems with
glibc >= 2.16
(? only tested down to 2.17), but in myglibc-2.13
container it shows:I would expect to solve this if I can build
libcoreclr.so
on aglibc-2.13
system (container), but obviously cannot bootstrap it as./build.sh
itself throws this error since it relies onlibcoreclr.so
.Does that mean I need to cross-compile (on a system which has at least
glibc-2.16
), and if so, is it feasible to build the rootfs for the cross-compile withglibc-2.13
? Would this work, or should I expect more blockers down the line?Beta Was this translation helpful? Give feedback.
All reactions