DSL Ideas and Suggestions :: Flash 9 environment

yes...

I just now saw that there is a libc6.dsl in the extensions area. version 6_2.3.2.ds1-22_i386.deb. I am curious if that is the one that is now in the base system. I will try it out when I get home, it was right there and I didn't see it. I am going to build glibc 2.3.2 vanilla and see how it works, to see if these errors and such are just simply from 2.3.2 being an older release, which is probably the case.

EDIT: The installed version in DSL seems to be libc6-ds1-10, also a debian package. And I have not had a good experience using the libc6.dsl from the extension area, I was going to test it with Firefox/Flash but xterm would not launch when I had the same gtk2/alsa extensions loaded that work ok otherwise.

Perhaps this sheds some light:
http://forums.gentoo.org/viewtopic.php?p=285261

According to it when glibc 2.3.2 came it broke a lot of stuff. Because of this, Jason you should try 2.3.6 instead, it's at least known to be working fine in several distros.

Also:

Quote

My problem was fixed by updating to glibc 2.3.6.

The flash plugin does a call to dlclose when it is unloaded, as can be seen in this backtrace:
#0 0x40d822c4 in _dl_close () from /lib/libc.so.6
#1 0x401f3d7a in dlclose_doit () from /lib/libdl.so.2
#2 0x4000c460 in _dl_catch_error () from /lib/ld-linux.so.9
#3 0x401f42cb in _dlerror_run () from /lib/libdl.so.2
#4 0x401f3daa in dlclose () from /lib/libdl.so.2
#5 0x44115c4e in NP_Shutdown () from /usr/firefox/plugins/libflashplayer.so
#6 0x44128702 in NP_Shutdown () from /usr/firefox/plugins/libflashplayer.so
#7 0x44027468 in Flash_EnforceLocalSecurity ()
from /usr/firefox/plugins/libflashplayer.so
#8 0x440230a0 in ?? () from /usr/firefox/plugins/libflashplayer.so
#9 0x4477c460 in ?? () from /usr/firefox/plugins/libflashplayer.so
#10 0x4477be20 in ?? () from /usr/firefox/plugins/libflashplayer.so
#11 0xbfffefdc in ?? ()
#12 0x446b587a in ?? () from /usr/firefox/plugins/libflashplayer.so
#13 0x4477abfc in ?? () from /usr/firefox/plugins/libflashplayer.so
#14 0x40dacff4 in ?? () from /lib/libc.so.6
#15 0xbffff2cc in ?? ()
#16 0x40d82a73 in _dl_close () from /lib/libc.so.6

Recursive calls to dlclose have been fixed between glibc 2.3.5 and glibc 2.3.6:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1081

Taken from http://www.adobe.com/cfusion....hread=y

Thanks curaga. I had stopped at building 2.3.2 from source since your last post is not the first time that I read of 2.3.2 being buggy in and of itself. And with the 2.3.2 in base DSL appears to be a Debian package, it surely has some patches and fixes that the bare source would not. Just evidently not as much patching/fixing as in the latest Sarge version updated as of last year. And this latest Sarge version seems to have bugfixing that has been backported from the later releases of glibc.
If I make a go at building a glibc I will build 2.3.6 since by all accounts it seems pretty mature and stable. But Sarge's 2.3.2 is only a few kilobytes larger than the libc6 in base DSL. And with Flash, BOINC, and the compiling that I have done the last couple days, Sarge's libc6 seems very solid and compatible with some newer things. I have put my machine to the test and I have not seen any issues arising from the updated libc6.
It would be nice to see how 2.3.6 would perform, and perhaps I will build it in the next coming weeks to test drive. It would be nice to keep around for those apps that would require it and no less.

EDIT: Getting off topic, but I am running Firefox 3 RC2 now that I also installed a couple of other Sarge debs - libgcc1, and libstdc++6. Some newer stuff could be run with these libs, but Swiftfox requires a newer glibc. But the gtk1 build of Firefox from lamarelle.org does work. And those two .deb packages are only about 400kb compressed, with the docs and man pages and all. I think an extension of these libs would be handy.

$0.02: If it doesn't appear to break anything, I think it would be great if dsl's glibc was replaced with Sarge's.

I only wish someone had worked this out earlier. Thanks Jason.

Next Page...
original here.