[gentoo-dev] libc.so.6 error

[gentoo-dev] libc.so.6 error

[Ajai Khattri]

Can anyone explain this?

# /lib/libc.so.6
Inconsistency detected by ld.so: rtld.c: 1252: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_prev->l_next ==
_rtld_local._dl_rtld_map.l_next' failed!

I am using 2.6.5-gentoo-r1 kernel and libc was compiled with nptl enabled.

-- 
Aj.
Sys. Admin / Developer

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] helixplayer-bin question, and wget with https proxy

[Joel Martin]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

Background: Yesterday I bumped the revision of helixplayer-bin from
0.3.0.71 to 0.3.0.124. Both of these releases of helixplayer require
a click through in order to download (i.e. fetch restriction).

However, today, the Alpha version of helixplayer was released, this
version doesn't require a click through in order to download. However,
this version is 0.3.0.123 which is older than the one with fetch
restrictions. 

So, how do I communicate to people merging this package, that what they
probably want is 0.3.0.123, even though there is a newer package.

Options:
- Just remove the ebuilds with fetch restrictions.
- Make the 0.3.0.123 stable right now (probably the wrong route)
- Make the ones with fetch restrictions -x86, so that the user has to
  force it. This is the one I'm leaning towards, because this way,
  enterprising users have the ebuild to use the fetch restricted
  helixplayer, but most users just get the alpha version 0.3.0.123 and
  don't have to worry about fetch restrictions.


Another question:

Also, I am behind a proxy (which I'm sure many people are). The download
for helixplayer is at a https link only
(https://helixcommunity.org/download.php/410/hxplay-0.3.0.123-linux-2.2-libc6-gcc32-i586.tar.bz2).
I can't get wget to proxy https through our proxy (I have to use firefox
to download the file to distfiles). I read something that said wget 1.9
doesn't work properly with https proxying? 1.9 is the stable version in
portage.

I guess it will be okay once the helixplayer download propogates to the
mirrors, but it still doesn't seem like the ideal situation.



Any guidance for either issue?


P.S. Also, for those of you following helixplayer/realplayer stuff,
there is also a source download (also not fetch restricted) on the alpha
download page:
https://helixcommunity.org/project/showfiles.php?group_id=154

It's ugly though because they use their own weird build system. Anybody
else want to take a crack at getting it working? I'm not sure I'll have
the time anytime soon.


-- 
Joel Martin  --  kanaka

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] helixplayer-bin question, and wget with https proxy

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On 05/18/04  Joel Martin wrote:

> Options:
> - Just remove the ebuilds with fetch restrictions.
> - Make the 0.3.0.123 stable right now (probably the wrong route)
> - Make the ones with fetch restrictions -x86, so that the user has to
>   force it. This is the one I'm leaning towards, because this way,
>   enterprising users have the ebuild to use the fetch restricted
>   helixplayer, but most users just get the alpha version 0.3.0.123 and
>   don't have to worry about fetch restrictions.

If the 123 and 124 versions are identical otherwise I'd go for option
one or package.mask'ing 124, I don't like using KEYWORDS for such stuff
(as -arch means: "doesn't work", not: "is inconvienient"). package.mask
has the advantage that you can provide a comment to explain why you
masked it.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] libc.so.6 error

[Stefan Jones]

Known problem, it is fixed in the unstable glibc versions.

There is probably a bug open about it.

I think it happened because libc.so is a shared executable which does not
rely on libc and the lists got mucked up.

Stefan

Ajai Khattri said:
>
> Can anyone explain this?
>
> # /lib/libc.so.6
> Inconsistency detected by ld.so: rtld.c: 1252: dl_main: Assertion
> `_rtld_local._dl_rtld_map.l_prev->l_next ==
> _rtld_local._dl_rtld_map.l_next' failed!
>
> I am using 2.6.5-gentoo-r1 kernel and libc was compiled with nptl enabled.
>
> --
> Aj.
> Sys. Admin / Developer
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list