Re: glibc 2.1.1 linking problems
On 28 Apr 1999, Stephen Zander wrote: > New data point for you: glibc2.1.1 *still* fails with a stock 2.2.6 > kernel on my SS5-170 at home. > > The 170 is, however, special in it's MMU configuration (Derrick only > added 170 support to the 2.0 kernels around 2.0.3[56]). I can > probably test it on an SS5-110 at work that is currently a stock > Debian 2.1 system, but I was keeping that box clean to use for > securing NMUs etc. Does glibc2.1 require any other packages to be > upgraded, e.g. sysvinit? The SS5/170 patch I did (which was very simple) was rolled forward into 2.1 and should be in any 2.2 kernel. Of course for the moment this is all elementary since I have neither a SS5/170 nor the time to work on anything, at least for the next 7 days -D
Re: glibc 2.1.1 linking problems
On Wed, Apr 28, 1999 at 05:46:05PM +0200, Gergely Madarasz wrote: > On Wed, 28 Apr 1999, Collins M. Ben wrote: > > > It requires only the latest cvs kernel for the sun4m. Sun4[cu] and > > seemingly sun4d only need a 2.2.x kernel of some kind. > > I'm fighting with this sun4d again... SMP won't boot, loadkeys freezes it, > sometimes there are other freezes... how do I access the cvs kernel ? And > on which list should I ask about these problems ? vger ? http://cvs.on.openprojects.net has the anon cvs info, for specific questions, I'd suggest the [EMAIL PROTECTED] list or it's archives.
Re: glibc 2.1.1 linking problems
On Wed, 28 Apr 1999, Collins M. Ben wrote: > It requires only the latest cvs kernel for the sun4m. Sun4[cu] and > seemingly sun4d only need a 2.2.x kernel of some kind. I'm fighting with this sun4d again... SMP won't boot, loadkeys freezes it, sometimes there are other freezes... how do I access the cvs kernel ? And on which list should I ask about these problems ? vger ? -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: glibc 2.1.1 linking problems
On Wed, Apr 28, 1999 at 08:22:57AM -0700, Stephen Zander wrote: > > "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: > Ben> Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run > Ben> better on sparc anyway. IPX is sun4c correct? If so then you > Ben> can use the stock 2.2.5 source and the glibc 2.1.1 should > Ben> work just fine. > > New data point for you: glibc2.1.1 *still* fails with a stock 2.2.6 > kernel on my SS5-170 at home. > > The 170 is, however, special in it's MMU configuration (Derrick only > added 170 support to the 2.0 kernels around 2.0.3[56]). I can > probably test it on an SS5-110 at work that is currently a stock > Debian 2.1 system, but I was keeping that box clean to use for > securing NMUs etc. Does glibc2.1 require any other packages to be > upgraded, e.g. sysvinit? It requires only the latest cvs kernel for the sun4m. Sun4[cu] and seemingly sun4d only need a 2.2.x kernel of some kind. > Alternatively, I can try the latest cvs kernel, but how bleeding edge > do we want to be? The CVS kernel is just like the stock one. Things that are unstable are marked with [EXPIERAMENTAL], but the reason for the CVS is to keep the sparc and ppc arch in sync with general kernel changes. It's actually more stable in most cases becuase of this, and is usually required to even compile the latest kernels for sprc (2.2.[56] being the latest exceptions). Again, the only problem we are having is sun4m requirng a very recent kernel version. Glibc 2.1.1 will have to atleast recommend this kernel once it is in the archive.
Re: glibc 2.1.1 linking problems
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run Ben> better on sparc anyway. IPX is sun4c correct? If so then you Ben> can use the stock 2.2.5 source and the glibc 2.1.1 should Ben> work just fine. New data point for you: glibc2.1.1 *still* fails with a stock 2.2.6 kernel on my SS5-170 at home. The 170 is, however, special in it's MMU configuration (Derrick only added 170 support to the 2.0 kernels around 2.0.3[56]). I can probably test it on an SS5-110 at work that is currently a stock Debian 2.1 system, but I was keeping that box clean to use for securing NMUs etc. Does glibc2.1 require any other packages to be upgraded, e.g. sysvinit? Alternatively, I can try the latest cvs kernel, but how bleeding edge do we want to be? -- Stephen --- Long noun chains don't automatically imply security. - Bruce Schneier
Re: glibc 2.1.1 linking problems
Ben Collins <[EMAIL PROTECTED]> writes: > That's what we are trying to determice. It will actually depend on a > specific version of kernel or > due to the sun4m problems. Since this > isn't in the archive yet, we haven't completely setup the > dependency/conflicts. This is worse than unstable, it's testing in > progress :) this is why i am running linux on a sparc machine, to test. i am running linux on intel for my daily work, and linux on powerpc/alpha/sparc for fun/hacking. if we didn't have problems like this it would be kind of boring. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: glibc 2.1.1 linking problems
James Moody <[EMAIL PROTECTED]> writes: > I'm running unstable on a stock 2.2.6 on an IPX. But I'm only running > glibc 2.0.105-2, and I have the same behaviour with apt 0.3.whatever. > I downgraded the apt package to the version from stable (0.1.9) and > apt works fine. > More info available upon request. > yes, apt didn't work with libc 2.0.105 for me either. i upgraded to libc 2.1.1 mostly to see if it cured the problems with apt, but it didn't. i tried running apt-get -f update under strace, but i get a core dump if i do that. maybe strace doesn't quite work either. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: glibc 2.1.1 linking problems
> Ben Collins <[EMAIL PROTECTED]> writes: > > > Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run better on > > sparc anyway. IPX is sun4c correct? If so then you can use the stock > > 2.2.5 source and the glibc 2.1.1 should work just fine. > > > > yes, IPX is a sun4c. i am running the stock 2.2.6 kernel and glibc > 2.1.1 and everything is fine except for apt. if glibc 2.1.1 requires a > 2.2 kernel shouldn't the debian package conflict with 2.0 kernels, or > at least depend on 2.2 ones? i have switched to dpkg-ftp to keep the > machine updated until i can figure out why apt-get hangs. I'm running unstable on a stock 2.2.6 on an IPX. But I'm only running glibc 2.0.105-2, and I have the same behaviour with apt 0.3.whatever. I downgraded the apt package to the version from stable (0.1.9) and apt works fine. More info available upon request. james
Re: glibc 2.1.1 linking problems
Just a note: glibc 2.1.1 works on sun4d with a stock 2.2.5 kernel. -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: glibc 2.1.1 linking problems
On Tue, Apr 27, 1999 at 04:39:44PM -0700, Alex Romosan wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run better on > > sparc anyway. IPX is sun4c correct? If so then you can use the stock > > 2.2.5 source and the glibc 2.1.1 should work just fine. > > > > yes, IPX is a sun4c. i am running the stock 2.2.6 kernel and glibc > 2.1.1 and everything is fine except for apt. if glibc 2.1.1 requires a > 2.2 kernel shouldn't the debian package conflict with 2.0 kernels, or > at least depend on 2.2 ones? i have switched to dpkg-ftp to keep the > machine updated until i can figure out why apt-get hangs. That's what we are trying to determice. It will actually depend on a specific version of kernel or > due to the sun4m problems. Since this isn't in the archive yet, we haven't completely setup the dependency/conflicts. This is worse than unstable, it's testing in progress :) -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation -- -- - - - --- --- -- - - --- - --
Re: glibc 2.1.1 linking problems
Ben Collins <[EMAIL PROTECTED]> writes: > Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run better on > sparc anyway. IPX is sun4c correct? If so then you can use the stock > 2.2.5 source and the glibc 2.1.1 should work just fine. > yes, IPX is a sun4c. i am running the stock 2.2.6 kernel and glibc 2.1.1 and everything is fine except for apt. if glibc 2.1.1 requires a 2.2 kernel shouldn't the debian package conflict with 2.0 kernels, or at least depend on 2.2 ones? i have switched to dpkg-ftp to keep the machine updated until i can figure out why apt-get hangs. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: glibc 2.1.1 linking problems
On Tue, Apr 27, 1999 at 02:38:35PM -0700, Alex Romosan wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > > > Kernel version? Previous libc6 version? SPARC arch? (sun4[cdmu]) > > > > i was running 2.0.35 and libc6 2.0.105 on a sparc staion ipx. in the > mean time i managed to fix my system by extracting the old libc > library to a temporary directory and then copying it to /lib and > running ldconfig -v. once i got the system sort of working again, i > compiled 2.2.6 (which i am running right now) and installing libc > 2.1.1 went without any problems. i remember having the same problems > on a powerpc (with chown and 2.0.x vs > 2.1.100 kernels). anyway > things are sort of back to normal now. the only problem i still have > is with apt-get it just sits there forever using up 100% cpu time. > this is apt 0.3.4. if anybody has any ideas how to fix this please let > me know. Bingo, glibc 2.1.1 requires a 2.2 kernel. The 2.2 kernels run better on sparc anyway. IPX is sun4c correct? If so then you can use the stock 2.2.5 source and the glibc 2.1.1 should work just fine. -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation -- -- - - - --- --- -- - - --- - --
Re: glibc 2.1.1 linking problems
Ben Collins <[EMAIL PROTECTED]> writes: > > Kernel version? Previous libc6 version? SPARC arch? (sun4[cdmu]) > i was running 2.0.35 and libc6 2.0.105 on a sparc staion ipx. in the mean time i managed to fix my system by extracting the old libc library to a temporary directory and then copying it to /lib and running ldconfig -v. once i got the system sort of working again, i compiled 2.2.6 (which i am running right now) and installing libc 2.1.1 went without any problems. i remember having the same problems on a powerpc (with chown and 2.0.x vs > 2.1.100 kernels). anyway things are sort of back to normal now. the only problem i still have is with apt-get it just sits there forever using up 100% cpu time. this is apt 0.3.4. if anybody has any ideas how to fix this please let me know. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: glibc 2.1.1 linking problems
On Mon, Apr 26, 1999 at 08:07:09PM -0700, Alex Romosan wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 26, 1999 at 07:12:29PM -0400, Steve Dunham wrote: > > > > > > It's your favorite debian developer again. :) > > > > > > Your glibc "chown" hack has one minor problem: Old libraries which > > > reference "chown@@GLIBC_2.1" won't link (compile time) with the new > > > libc. (The load-time linking works fine.) > > > > Interesting, I hadn't noticed it really. > > i installed libc6 2.1-1 from master.debian.org/~bcollins and now the > whole system is dead. dpkg doesn't work, i can't seem to be able to > log in remotely. i get something like chown not implemented. ldd > doesn't work and so on. any ideas how i can fix this? Kernel version? Previous libc6 version? SPARC arch? (sun4[cdmu]) -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation -- -- - - - --- --- -- - - --- - --
Re: glibc 2.1.1 linking problems
Ben Collins <[EMAIL PROTECTED]> writes: > On Mon, Apr 26, 1999 at 07:12:29PM -0400, Steve Dunham wrote: > > > > It's your favorite debian developer again. :) > > > > Your glibc "chown" hack has one minor problem: Old libraries which > > reference "chown@@GLIBC_2.1" won't link (compile time) with the new > > libc. (The load-time linking works fine.) > > Interesting, I hadn't noticed it really. i installed libc6 2.1-1 from master.debian.org/~bcollins and now the whole system is dead. dpkg doesn't work, i can't seem to be able to log in remotely. i get something like chown not implemented. ldd doesn't work and so on. any ideas how i can fix this? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: glibc 2.1.1 linking problems
Ben Collins <[EMAIL PROTECTED]> writes: > On Mon, Apr 26, 1999 at 07:12:29PM -0400, Steve Dunham wrote: > > > > It's your favorite debian developer again. :) > > > > Your glibc "chown" hack has one minor problem: Old libraries which > > reference "chown@@GLIBC_2.1" won't link (compile time) with the new > > libc. (The load-time linking works fine.) > > Interesting, I hadn't noticed it really. > > > This probably isn't too give us _too_ much trouble, but the following > > will have to be recompiled: > > > > libguile.so.3 > > libguile.so.4.0.0 > > libpwdb.so.0.54 > > librpm.so.1.0 > > libtck8.0.so.1 > > Ok, this will not be too hard once I finish setting up the permanent > wanna-build/buildd for sparc. So does compiling with this egcs/glibc > still run on RedHat? I don't have a RH box to check this at the moment, but I doubt there is a problem. The problem that I referred to was the RH binaries wouldn't run on Debian, because of a missing register_frame_info symbol in our libc. But apparently our libc now has this symbol, so there shouldn't be a problem. Steve [EMAIL PROTECTED]
Re: glibc 2.1.1 linking problems
On Mon, Apr 26, 1999 at 07:12:29PM -0400, Steve Dunham wrote: > > It's your favorite debian developer again. :) > > Your glibc "chown" hack has one minor problem: Old libraries which > reference "chown@@GLIBC_2.1" won't link (compile time) with the new > libc. (The load-time linking works fine.) Interesting, I hadn't noticed it really. > This probably isn't too give us _too_ much trouble, but the following > will have to be recompiled: > > libguile.so.3 > libguile.so.4.0.0 > libpwdb.so.0.54 > librpm.so.1.0 > libtck8.0.so.1 Ok, this will not be too hard once I finish setting up the permanent wanna-build/buildd for sparc. So does compiling with this egcs/glibc still run on RedHat? -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation -- -- - - - --- --- -- - - --- - --
glibc 2.1.1 linking problems
It's your favorite debian developer again. :) Your glibc "chown" hack has one minor problem: Old libraries which reference "chown@@GLIBC_2.1" won't link (compile time) with the new libc. (The load-time linking works fine.) This probably isn't too give us _too_ much trouble, but the following will have to be recompiled: libguile.so.3 libguile.so.4.0.0 libpwdb.so.0.54 librpm.so.1.0 libtck8.0.so.1 On the affected libraries, objdump -T will include: DF *UND* 00a4 GLIBC_2.1 chown Note that the current versions of the libraries will work with the new glibc, but you won't be able to build new programs using both the current versions of the above libraries and the new glibc. Steve [EMAIL PROTECTED]
