You are not logged in.
I've installed the new toolchain and my computer hasn't exploded yet, I am not having any problems at the moment.
I could compile my custom kernel just fine, but other packages failed to compile throwing these kind of errors
/usr/bin/ld: /usr/lib/libx265.so.199: reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' not defined
Can you give an exact example of a package that fails like this? This seems to be in the realm of a partial update.
Edit: I can see this...
Offline
Also the new toolchain doesn't move the --enable-install-libiberty to binutils. Do you think it's worth to open a bug report? I installed the new staging toolchain. so far no issue.
It is as if every improvement people provided patches for was ignored...
Edit: I am told this was intended "just to get the update" and other things will be merged in the coming weeks.
Offline
Hey people,
thank you for posting here. Your voice is heard and while compiling the toolchain this thread helped a lot!
I intentionally went for a fast release to have glibc 2.35 out rather soon than to make a lot of changes with the first release after months and a new maintainer.
I'm looking at the patches now and start running tests.
Offline
Hey freswa, thank you so much for your work and contribution.
Offline
but other packages failed to compile throwing these kind of errors
/usr/bin/ld: /usr/lib/libx265.so.199: reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' not defined
Turns out that if libx265 is compiled with latest binutils (as the variant in [testing] is), then this is "fixed". Now to figure out why...
Offline
loqs wrote:agapito wrote:Sadly with CET still enabled [1].
Any chance you want to open a bug report with more explanation than a very long mailing list link?
https://bugs.archlinux.org/task/73708
Brief summary glibc upstream expected CET to be left off as it was by default until kernel support was finalized. Without kernel support it does not work, with a kernel supporting the current proposed interface it will not work as expected and can produce segfaults.
Offline
agapito wrote:I've installed the new toolchain and my computer hasn't exploded yet, I am not having any problems at the moment.
I could compile my custom kernel just fine, but other packages failed to compile throwing these kind of errors
/usr/bin/ld: /usr/lib/libx265.so.199: reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' not defined
Can you give an exact example of a package that fails like this? This seems to be in the realm of a partial update.
Edit: I can see this...
obs-studio-git from AUR. I'm using the staging repo by the way.
EDIT: Manually rebuilding some packages from staging repo, made errors gone away.
Last edited by agapito (2022-02-12 15:40:23)
Excuse my poor English.
Offline
Hey people,
thank you for posting here. Your voice is heard and while compiling the toolchain this thread helped a lot!
I intentionally went for a fast release to have glibc 2.35 out rather soon than to make a lot of changes with the first release after months and a new maintainer.
I'm looking at the patches now and start running tests.
Thanks a lot! FWIW I've installed the toolchain from testing and compiled a couple small packages (termite, yambar-git, personal PKGBUILDS) without any issues - so far everything's working smoothly here...
Last edited by dogknowsnx (2022-02-10 08:57:17)
Offline
Thanks to all for getting this into testing. If I install it however it doesn't quite work yet for my packages. Is there any way to trigger packages that need new glibc to reinstall or just be patient? I guess I could switch some distribution packages to -git versions and if they compile, great?
Edit: Got everything working, thanks all
Last edited by afader (2022-02-15 00:52:17)
Offline
Thanks to all for getting this into testing. If I install it however it doesn't quite work yet for my packages. Is there any way to trigger packages that need new glibc to reinstall or just be patient? I guess I could switch some distribution packages to -git versions and if they compile, great?
"doesn't quite work" is the vaguest description of a problem... That gives us nothing to go on to fix your issues.
Offline
Edit: Got everything working, thanks all
Last edited by afader (2022-02-15 00:52:33)
Offline
Looks like the core glibc package was updated last night. Thanks to the maintainers
Offline
And with that, I shall close this thread.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline