Comments (17)
make AppRun
works, make runrime
fails.
from appimagekit.
memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14
= problem with LibcWrapGenerator
, try with cmake . -DUSE_LIBC_WRAP_GENERATOR=OFF
from appimagekit.
Yes, I can confirm that. Also see #49
from appimagekit.
Do you know how to pass in -U_FORTIFY_SOURCE
?
from appimagekit.
Already doing it LibcWrapGenerator/cc
(as you already noticed in the email)
Is memcpy a "too new" symbol?
Shouldn't be, but this error was already happening in Tristan's blog comments and in theory it was a fixed bug, but it seems to persist even though we seem to have the latest version of LibcWrapGenerator.vala
from appimagekit.
I've disabled LibcWrapGenerator by default in d36f076
from appimagekit.
Well I think we can use it if we set --target 2.14
. Or do you have some other rationale for entirely abandoning it?
from appimagekit.
Should --target 2.14
work better than the current --target 2.7
?
Anyway, we're not abandoing it entirely, it's just set off by default; and my only rationale for doing so right now is that it's breaking CI in the experimental branch, so it's blocking any other change (like 3eae15e), and any further experiment should be moved to a feature branch until it's proven stable
from appimagekit.
Yes, it allows symbols that were introduced between 2.7 and 2.14 to be used. Works for head.
from appimagekit.
Makes sense, will try it on a new branch. If it works, should I enable by default again? Do you think it's stable enough?
from appimagekit.
Indeed, compiling against 2.14 works but against 2.7 doesn't
I finally understood the problem checking LibcWrapGenerator's README, and I'm not sure using glibc 2.14 is desirable:
Now, in glibc 2.14, it was decided that many programmers used memcpy() in
cases where they actually desired the behaviour of memmove(), or their
code was found to be unsafe, so in the interest of creating a more stable glibc,
they have provided us with a new implementation of memcpy() which does that.
That new symbol is named 'memcpy@GLIBC_2.14' in the new glibc ABI.If you update your system's glibc, or distribute that very same binary
on a system with glibc 2.16, glibc will still contain the old version of
memcpy() bound to the 'memcpy@GLIBC_2.2.5' symbol in it's lookup table.And there you have forward binary compatibility for your program.
But what we want is the very opposite of the above. We want to use a modern
GNU toolchain on a modern system with a modern glibc, but we want to have
our programs backwards compatible for much older versions of glibc.
So if I understand correctly, doesn't forcing glibc 2.14 destroy the very purpose of using LibcWrapGenerator? See for instance https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/comment-page-1/#comment-3831:
The memcpy function should not fall under the DONT_USE_THIS_VERSION category but rather be directed to 2.2.5, so if you are targeting any libc version > 2.2.5 then this shouldn’t happen (but as I only have my own glibc to test against, I can’t be sure yet that it’s parsing objdump output properly).
from appimagekit.
The way I read it, with the current code we have and with LibcWrapGenerator we can at least ensure that no later than 2.14 must be installed, so yes I still think it's worthwhile. It will also warn us if future code tries to use functionality that is not supported in 2.14. That alone makes it worthwhile imho.
from appimagekit.
Indeed 2.14 should be old enough, but I'm afraid the problem is LibcWrapGenerator is not working correctly, and may fail again in a future:
- My Archlinux is using glibc 2.22, but is able to target glibc 2.7, using
memcpy()
from 2.2.5. - Travis VM is using glibc 2.16, and for some reason is not able to target glibc 2.7, and instead must target the glibc version with the next version of
memcpy()
, which is 2.14. - Same happens on Fedora 23
This means, if memcpy()
changes again in 2.23, LibcWrapGenerator will fail again on us when targeting glibc 2.14 on some machines with glibc 2.23 or higher installed, regardless of whether glibc 2.14 supports the features we're using or not, just like it's doing right now when targeting glibc 2.7 on Travis or Fedora.
I mean, for now we can take advantage of these two version of glibc LibcWrapGenerator is taking us back (2.16 -> 2.14), but it's not really working on some machines, so it's not stable tech we can rely on, as it will eventually break the build on some machines unless these errors are tracked and fixed (if possible).
Tristan (creator of LibcWrapGenerator) once told me:
Ultimately though, this is not well supported by the maintainers of glibc, a much more stable approach to this is to just compile against the oldest version of glibc you intend to support - however this of course also has it's own complications (it's damn tricky to parallel install glibc and have your compiler use the alternative glibc).
from appimagekit.
Oh wow. That stuff is really tricky... didn't know that. Do the same restrictions apply for https://github.com/ximion/limba/blob/master/contrib/licompile/ligcc? If I understand it correctly, it is following a very similar idea as LibcWrapGenerator.
from appimagekit.
No idea, but maybe we're facing a LibcWrapGenerator bug that the libgcc guys have figured out
from appimagekit.
Is this really old issue still relevant? I don't think anyone uses LibcWrapGenerator any more.
from appimagekit.
This was regarding the old master
branch that has been stale for quite some time now, so closing. Nevertheless, LibcWrapGenerator can be be a solution in some cases if you need to build on a relatively new build system and want to target older systems. But using an old build system is a more robust solution, and is what we are using now.
from appimagekit.
Related Issues (20)
- setup HOT 1
- Adding Github Sponsorship option HOT 1
- [docs] Add fedora fuse-libs to the wiki HOT 5
- Cannot mount AppImage, please check your FUSE setup on Debian 11 HOT 2
- Any timeline for an updated version? HOT 5
- appimagetool-i686.AppImage: cannot execute: required file not found HOT 1
- Unable to extract LBRY_0.53.9.AppImage HOT 4
- AppImage run troubles
- Run built AppImage on Yocto HOT 2
- Some Appimages stopped showing icons. HOT 7
- Monochrome logo HOT 1
- Does some way exist for an AppImage to create temporary a temporary x-scheme-handler? HOT 4
- Static appimage with new runtime gives a strange error on a Pop OS! 22.04 computer HOT 1
- AppImage hangs on startup when using fuse HOT 6
- Ubuntu 24.04 not booting after installing fuse
- Using DB like Cassandra in AppImage's way
- LinuxDeploy+AppImage don't handle all SDL2 dependencies + glibc version mismatch HOT 1
- fusermount: mounting over filesystem type 0x858458f6 is forbidden | debian testing
- Wiki for FUSE could mention libfuse2t64 from Ubuntu 24.04 HOT 2
- Add to Wiki page update with instruction to fix ubuntu after installation fuse HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from appimagekit.