Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
On 2014-01-11 10:06 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 01/08/2014 01:03 PM, Tanstaafl wrote: Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 You really do not want to do that. These are set by the profile, and when updates come around (like python 3.4) your system won't get it because you manually said you wanted python 3.3. Please, nobody should be setting this variable randomly in make.conf. When in doubt, don't change the defaults from the profile. You can see what is set for everything with emerge --info. I didn't set it (yet), I don't change things like this without learning whether or not it is really needed - which is why I asked the question. ;) That said... emerge --info shows no mention of anything PYTHON related, much less either of these. Hmmm... it also doesn't show: PHP_INI_VERSION=production PHP_TARGETS=php5-5 Which I have explicitly set in /etc/portage/make.conf Shouldn't they be showing?
Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/08/2014 01:03 PM, Tanstaafl wrote: Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 You really do not want to do that. These are set by the profile, and when updates come around (like python 3.4) your system won't get it because you manually said you wanted python 3.3. Please, nobody should be setting this variable randomly in make.conf. When in doubt, don't change the defaults from the profile. You can see what is set for everything with emerge --info. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS0gavAAoJEKXdFCfdEflKGHQQAJkP/3fSeF1+gL7DhLkxvj+r rZAhUZ14p6nho6QGzLZIrzzj+ujHK+iB85Nh+J3SsS6l+/9070kP1yqg6d4PsrKE KPSmm1Fb6b+JN+x2ccXtyfDys5s9u5if9pOuf1xQKPPJb+GOPYrXeyW1HK6bR4Ak lhAisDpMiv6xeO0QAHwlyt4RntbweOdvPJDe6i7ZhSN/5YNX+vGQNlbzVQ+8o0W8 HMRDlokw3Zqi9XgdcfaJzCQ5NtXHxIS6vhdpSzvvD16D8acRcDhlxc3YcRGwKryp gpVOk/WjYXY11nNhJAkuyEetDEVPFFFTg4Vfb/ZSDsGBDF+EliP/IvNUOFpdxS3a /Mu31sedaOHjiFRaLLwHm8owmVSjYvbo1G3A95stoWhV/gUJGz3Srxw1RPd8iPwi h/zQi24bjWVVmN4WOjvkP6hG4HCDf+MOOA03vB3jEQWHrTaHMbT2ezLwx+++crxx kA69m9ohKdXaWc1w88C6d+v4r/FvAibpECVFS/Z5tCHs9HiQVtp8vdXwGyT6Ac8j 3ARekki6FxgbFPQ2qXNXzbOcFd3SGlHnaiPW4/yeqKMdxMj4IMVElSAon/fVnWJd 0meS8J8mfK6Lgx3IMziowQ2ZkAD4AofNmtX0iiMygA1E6vCqsGthmO0wmuoQja3P pO1Vkzw0FE9sbg1VJqXh =XeIY -END PGP SIGNATURE-
Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
On 08/01/2014 20:03, Tanstaafl wrote: On 2014-01-08 11:54 AM, Tanstaafl tansta...@libertytrek.org wrote: I just updated glibc to 2.1.17, and got the following error at the very end of the emerge: /usr/bin/python2.7: relocation error: /lib64/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with lin k time reference Is this something to worry about? After some googling... Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 ? Just added them and am remerging glibc... sill see what happens... I doubt the missing entries are relevant, they just set defaults. Without PYTHON_TARGETS portage installs all python versions, the settings just restricts it to the ones you want. PYTHON_SINGLE_TARGET says which python to use if there can only be one, the ebuild normally sets this itself. I'd be surprised if the change made a difference, but if it does that would be an interesting bug to track down -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
On 2014-01-09 4:24 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 08/01/2014 20:03, Tanstaafl wrote: On 2014-01-08 11:54 AM, Tanstaafl tansta...@libertytrek.org wrote: I just updated glibc to 2.1.17, and got the following error at the very end of the emerge: /usr/bin/python2.7: relocation error: /lib64/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Is this something to worry about? After some googling... Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 ? Just added them and am remerging glibc... sill see what happens... I doubt the missing entries are relevant, they just set defaults. Without PYTHON_TARGETS portage installs all python versions, the settings just restricts it to the ones you want. PYTHON_SINGLE_TARGET says which python to use if there can only be one, the ebuild normally sets this itself. I'd be surprised if the change made a difference, but if it does that would be an interesting bug to track down Well... there was no error this time (did emerge -v1)... So, no idea on what the error message even meant? Googling reveals a few older references to it, but nothing substantial as far as a cause, or if it is anything to worry about.
Re: [gentoo-user] glibc update 2.16 2.17 - python relocation error at end of emerge
On 2014-01-08 11:54 AM, Tanstaafl tansta...@libertytrek.org wrote: I just updated glibc to 2.1.17, and got the following error at the very end of the emerge: /usr/bin/python2.7: relocation error: /lib64/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with lin k time reference Is this something to worry about? After some googling... Could this have anything to do with the fact that I don't have either of these set in /etc/portage/make.comf: PYTHON_TARGETS=python2_7 python3_3 PYTHON_SINGLE_TARGET=python2_7 ? Just added them and am remerging glibc... sill see what happens...
Re: [gentoo-user] glibc update
On Friday 20 March 2009 03:52:10 Jorge Morais wrote: This was a doubt of mine. One of the reasons I prefer to use a stable kernel is that I don't know if, when using a newer (and ~x86) kernel, I should also use the corresponding linux-headers version. So you say I can be 99.999% sure that, should I update my kernel (say, to 2.6.28) and meet problems, those will be intrinsic to this kernel version (and possibly to incompatibilities with things like out-of-tree kernel modules), but never because the kernel headers are outdated? Yes IOW, the only real problem of using outdated kernel headers is not fully taking advantage of new features? Yes -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc update
On Wed, 18 Mar 2009 23:49:12 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: msoul...@anton:~$ equery belongs /usr/include/linux/quota.h [ Searching for file(s) /usr/include/linux/quota.h in *... ] sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h) ul...@anton:~$ uname -a Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux So slightly off but compatible. At some point a newer glibc would simply fail to build if it's incompatible then, I assume? It is as close to guaranteed to build as you are ever going to get. The public interface to the kernel via it's headers simply does not change in incompatible ways. But if it ever did, then yes, glibc would fail to build This was a doubt of mine. One of the reasons I prefer to use a stable kernel is that I don't know if, when using a newer (and ~x86) kernel, I should also use the corresponding linux-headers version. So you say I can be 99.999% sure that, should I update my kernel (say, to 2.6.28) and meet problems, those will be intrinsic to this kernel version (and possibly to incompatibilities with things like out-of-tree kernel modules), but never because the kernel headers are outdated? IOW, the only real problem of using outdated kernel headers is not fully taking advantage of new features? I prefer to use stable software anyway, but it is important to know.
Re: [gentoo-user] glibc update
On Wednesday 18 March 2009 13:23:47 Michael P. Soulier wrote: Hello, Looking at what I'm about to pick up via emerge, I notice this [ebuild U ] sys-libs/glibc-2.8_p20080602-r1 [2.6.1] This immediately sets off alarm bells for me, since glibc is the basis of the whole system. If I pick this up do I have to rebuild everything? No, this one is safe. Here's what happens: You said glibc is the basis of the whole system. That's not quite true, it's actually glibc provides the C library, which is a collection of basic function calls that just about every other program uses sooner or later Quite a different thing actually. The interface the glibc presents to the rest of the machine doesn't reduce. Everything that your programs used to see, they will still see. What might happen is the glibc provides extra stuff, but that doesn't matter as your existing compiled programs don't know about it and can't use it. A lot like replacing a power outlet in your house - it looks the same as the old one so there's no need to buy a new toaster. If there's an issues, revdep-rebuild will pick them up. Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1. It looks great, till you start firefox and find that it doesn't run anymore... I've also frozen my kernel at 2.6.25 for now due to the nvidia-drivers package. I have to use an older one for 3D accel and it doesn't work with the newer kernels according to a bug report I saw. At some point I'm assuming that a new glibc will require a new kernel too, if the interface changes, so presumably I'll have to update eventually. No, glibc might need updated kernel headers. The compiler uses them when building glibc - the headers tell the compiler what data structures, functions etc look like so that the glibc it builds can talk to whatever kernel you choose to run later. The only time you really need to update the kernel headers is if they provide some new features you want to take advantage of. The interface that the kernel provides to userspace is virtually frozen and Linus simply never changes it. In short, updating glibc is as safe as updating any other piece of software, as long as it has no known major bugs that cause you issues. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc update
On 18/03/09 Alan McKinnon said: You said glibc is the basis of the whole system. That's not quite true, it's actually glibc provides the C library, which is a collection of basic function calls that just about every other program uses sooner or later I wasn't sure if any interface changes had been made. Looking at the glibc 2.8 release notes, it doesn't look like it but I wanted to check before upgrading. It makes me nervous. :) If there's an issues, revdep-rebuild will pick them up. Ok, good. Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1. It looks great, till you start firefox and find that it doesn't run anymore... So, how would I know, in general, whether it's safe to upgrade when it appears in my emerge output? Just ask here? My BSD box has a /usr/ports/UPDATING file that I check before upgrading ports for any notices... No, glibc might need updated kernel headers. The compiler uses them when building glibc - the headers tell the compiler what data structures, functions etc look like so that the glibc it builds can talk to whatever kernel you choose to run later. So will it use /usr/src/linux by default? If so then I'm ok... The only time you really need to update the kernel headers is if they provide some new features you want to take advantage of. The interface that the kernel provides to userspace is virtually frozen and Linus simply never changes it. Good to know. In short, updating glibc is as safe as updating any other piece of software, as long as it has no known major bugs that cause you issues. Ok, thanks for the response. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein signature.asc Description: Digital signature
Re: [gentoo-user] glibc update
On Wednesday 18 March 2009 20:05:27 Michael P. Soulier wrote: Sometimes, glibc is all fsck'ed up. Like sys-libs/glibc-2.9_p20081201-r1. It looks great, till you start firefox and find that it doesn't run anymore... So, how would I know, in general, whether it's safe to upgrade when it appears in my emerge output? Just ask here? My BSD box has a /usr/ports/UPDATING file that I check before upgrading ports for any notices... Well, this is gentoo and we don't need no stinking Changelogs on gentoo :-) Seriously, you are running a stable arch. All known issues should be resolved by the time glibc hits stable. You can always askhere, or look at b.g.o for any outstanding issues No, glibc might need updated kernel headers. The compiler uses them when building glibc - the headers tell the compiler what data structures, functions etc look like so that the glibc it builds can talk to whatever kernel you choose to run later. So will it use /usr/src/linux by default? If so then I'm ok... No, it goes nowhere near that directory. It uses /usr/include/linux From your responses it seems like you haven't figured out yet how the whole compile/link/header thing works, so here's the (quickish) version: If an application uses a library that is already built and located elsewhere, the compiler needs to know what the data structures and functions in that library look like. This information is in the library's source code, but to make life for everyone infinitely easier, it is by convention separated out into so-called header files. These files don't contain any executable source code, just the definitions of things implemented by the library and publicly available. The benefit is that to compile something, you only need the (small) header files, not the full collection of (large) source code. Even on gentoo we have this - when you emerge wget, it most certainly uses something provided by glibc, yet the glibc source code is not available at emerge time - but the glibc headers are. These headers can technically be placed anywhere. The convention is to put them in /usr/include and to tell your compiler to look there for headers. glibc in turn also needs headers for things it uses, and amongst others this is the kernel headers in /usr/include/linux/. This doesn't have to be the same headers for the kernel you are running, it just has to be compatible headers. To prove this, just reboot and choose a different kernel. Everything works, but glibc could not possibly have been built against both kernel's sources. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc update
On 18/03/09 Alan McKinnon said: Well, this is gentoo and we don't need no stinking Changelogs on gentoo :-) :) Seriously, you are running a stable arch. All known issues should be resolved by the time glibc hits stable. You can always askhere, or look at b.g.o for any outstanding issues Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :) No, it goes nowhere near that directory. It uses /usr/include/linux From your responses it seems like you haven't figured out yet how the whole compile/link/header thing works, so here's the (quickish) version: Actually I do, but I don't go anywhere near the kernel so I wasn't sure of the relationship between glibc and the kernel interfaces. I'm just wondering if /usr/include/linux is ever incompatible with my kernel, and what to do about it if it is. glibc in turn also needs headers for things it uses, and amongst others this is the kernel headers in /usr/include/linux/. This doesn't have to be the same headers for the kernel you are running, it just has to be compatible headers. To prove this, just reboot and choose a different kernel. Everything works, but glibc could not possibly have been built against both kernel's sources. I see that, for example, msoul...@anton:~$ equery belongs /usr/include/linux/quota.h [ Searching for file(s) /usr/include/linux/quota.h in *... ] sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h) ul...@anton:~$ uname -a Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux So slightly off but compatible. At some point a newer glibc would simply fail to build if it's incompatible then, I assume? Looking on a CentOS box I see that they package that directory in a package called glibc-kernheaders. Makes sense... Thanks, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpr52LLfFCPK.pgp Description: PGP signature
Re: [gentoo-user] glibc update
On Wed, Mar 18, 2009 at 4:43 PM, Michael P. Soulier msoul...@digitaltorque.ca wrote: On 18/03/09 Alan McKinnon said: Seriously, you are running a stable arch. All known issues should be resolved by the time glibc hits stable. You can always askhere, or look at b.g.o for any outstanding issues Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :) I assume he meant bugs.gentoo.org
Re: [gentoo-user] glibc update
On Wednesday 18 March 2009 23:43:50 Michael P. Soulier wrote: On 18/03/09 Alan McKinnon said: Well, this is gentoo and we don't need no stinking Changelogs on gentoo :-) :) : Seriously, you are running a stable arch. All known issues should be resolved by the time glibc hits stable. You can always askhere, or look at b.g.o for any outstanding issues Bulgarian Gay Organization? Sorry, googling for b.g.o is dangerous. :) hehehe, that's funny :-) bugs.gentoo.org b.g.o. is the common name used around here. Probably not the most obvious thing in the world though [snip] msoul...@anton:~$ equery belongs /usr/include/linux/quota.h [ Searching for file(s) /usr/include/linux/quota.h in *... ] sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h) ul...@anton:~$ uname -a Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux So slightly off but compatible. At some point a newer glibc would simply fail to build if it's incompatible then, I assume? It is as close to guaranteed to build as you are ever going to get. The public interface to the kernel via it's headers simply does not change in incompatible ways. But if it ever did, then yes, glibc would fail to build Looking on a CentOS box I see that they package that directory in a package called glibc-kernheaders. Makes sense... Thanks, Mike -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] glibc update 2.4 2.5 FAILED postinst causes everything to segfault
Michael [Plouj] Ploujnikov ha scritto:
Hi,
Before I file this as a bug I'd like to make sure it's not caused by
something wrong with my system. Please help me determine that.
In the past two days I was trying to upgrade my glibc from version 2.4
to 2.5. Each time I tried it the emerge process failed at the very
last point - I think when the actual files were being installed into
my system. Here is the relevant output:
Don't know if it's your system or a glibc bug (my upgrade went OK), but
anyway in the forums I found what seems to be a possible solution to
have a working system back (the poster had a similar, but not identical
problem):
I downloaded the 2006.0 livecd, boot it, chroot into my system and had
the same issues with grep, sed, et al. (not able to emerge anything).
exited the chroot, built a binary of glibc-2.3.5 in the CD environment
(emerge -B sys-libs/glibc), moved it to my packages dir
(/mnt/gentoo/usr/portage/packages/{All,sys-libs}/glibc-2.3.5...whatever
it was), jumped back into the chroot, emerged the binary which worked
and now i'm in the process of rebuilding my system (emerge linux-headers
emerge -e system emerge -e ...). I'm taking the opportunity to
move to gcc 4.1 (already done) and am building a new binary for glibc
2.3.6-r3 just incase the emerge of 2.4 dies blows things up again.
i'll report back here if and when it's working.
m.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glibc update 2.4 2.5 FAILED postinst causes everything to segfault
Michael [Plouj] Ploujnikov ha scritto: Hi, What happens after this is pretty nasty. Any program that I run segfaults: # ls Segmentation fault Try also using the emergency shell /bin/bb, it should be statically linked and therefore independent from glibc. m. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glibc update 2.4 2.5 FAILED postinst causes everything to segfault
On Saturday 03 March 2007 23:56:19 Michael [Plouj] Ploujnikov wrote: Before I file this as a bug I'd like to make sure it's not caused by something wrong with my system. Please help me determine that. In the past two days I was trying to upgrade my glibc from version 2.4 to 2.5. Each time I tried it the emerge process failed at the very last point - I think when the actual files were being installed into my system. Here is the relevant output: $ emerge -av glibc ... [SNIP] /lib64/libBrokenLocale.so.1 - libBrokenLocale-2.5.so !!! FAILED postinst: 2816 I couldn't find what that error means. What happens after this is pretty nasty. Any program that I run segfaults: I don't reallly have a clue if any of those are relevant but have a look yourself.. Otherwise go ahead and file the bug. http://tinyurl.com/yoebg6 -- Bo Andresen pgphayB1i3NEN.pgp Description: PGP signature
Re: [gentoo-user] glibc update 2.4 2.5 FAILED postinst causes everything to segfault
First of all, thanks for the replies. Just so you know, I was able to get my system to a working state. Read the bit about untarring the old glibc into my system in my email. I don't reallly have a clue if any of those are relevant but have a look yourself.. Otherwise go ahead and file the bug. http://tinyurl.com/yoebg6 Ok. I'll be looking at these in the near future. -- Libre Software: http://www.gnu.org/philosophy/free-sw.html -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glibc update 2.4 2.5 FAILED postinst causes everything to segfault
Michael [Plouj] Ploujnikov ha scritto: Try also using the emergency shell /bin/bb, it should be statically linked and therefore independent from glibc. Thanks. I had no idea I had that thing. Me too, but Google is always a bliss. :) m. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] glibc update and CHOST problem
On 8/31/06, Neil Isaac [EMAIL PROTECTED] wrote: I do have nptl and nptlonly in USE (that message had a yellow star, so I guess it's just a warning) but my CHOST is set to CHOST=i386-pc-linux-gnu in make.conf. How do I correct this problem? Assuming you are using a processor made in the last 10 years, just set CHOST=i686-pc-linux-gnu. You *must* do an emerge -e world after this, or you may very well break your system. In fact, I would recommend just following the gcc upgrade guide [1] and rebuild your whole system with the new CHOST and gcc 4.1. -Richard [1] http://www.gentoo.org/doc/en/gcc-upgrading.xml -- gentoo-user@gentoo.org mailing list
