From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 31 Oct 2003 11:48:03 +0200 From: Alexander Bokovoy To: community@altlinux.ru Subject: Re: [Comm] Glibc 2.3.2 Message-ID: <20031031094803.GB4318@sam-solutions.net> References: <20031030105647.E483748017@lrn.ru> <200310310806.49859.lighter@stl.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=cp1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200310310806.49859.lighter@stl.ru> X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: community@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 09:46:28 -0000 Archived-At: List-Archive: List-Post: On Fri, Oct 31, 2003 at 08:06:49AM +1000, Igor V. Krutyakov wrote: > В сообщении от 30 Октябрь 2003 20:56 Andrey Rahmatullin написал(a): > > > > У меня ALM 2.2. Скачал программу видеомонтажа одну, другую, обе требуют > > > glibc 2.3. В Мастере же 2.2.6, в Сизифе тоже только 2.2.6, только более > > > поздней сборки. На сайте же www.gnu.org текущая версия glibc - 2.3.2. > > > Собираются ли ребята из ALTLinux обновлять glibc? > > Пока нет AFAIK > Интересно, почему? Для меня, например, оказалось достаточным недостатков, упомянутых вот здесь: http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/es-x86/ В частности: Red Hat Enterprise Linux 3 includes the Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux. This library provides performance improvements and increased scalability. This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed. Notable differences include: · Signal handling has changed from per-thread signal handling to POSIX process signal handling. · getpid() returns the same value in all threads. · Thread handlers registered with pthread_atfork are not run if vfork() is used. · No manager thread. Applications that are known to have problems using NPTL include: - Sun JRE prior to version 1.4.1 - IBM JRE If an application does not work properly with NPTL, it can be run using the old LinuxThreads implementation by setting the following environment variable: LD_ASSUME_KERNEL= The following versions are available: · 2.4.19 — Linuxthreads with floating stacks · 2.2.5 — Linuxthreads without floating stacks Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed. # Multi-threaded C++ programs using thread cancellation might need to be forced to use the LinuxThreads library using the LD_ASSUME_KERNEL=2.4.19 environment variable setting. Otherwise, the program will terminate abnormally if the cancellation is acted on (since the generated exception is not caught). Newly-written C++ code that uses functions from the C runtime environment might have to be adjusted to take the cancellation into account. This can be done by one of the following methods: · Not marking the C++ function with throw() (so that callers are aware that an exception might be thrown) and by compiling the code with exceptions. This is the default compilation option; users should not specify -fno-exceptions when compiling. · Disabling cancellation completely before entering the functions that call the cancel-able C runtime functions. This can be done with the following call: pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate) After the C functions are called cancellation can be enabled again with the following call: pthread_setcancelstate (oldstate, NULL) NOTE: At this point the cancellations are acted upon and therefore the function calling pthread_setcancelstate() must be compiled with exceptions enabled and must be marked as throwing exceptions. У нас есть некоторое количество критических приложений, работающих только с Sun JRE <1.4.1. > > > Или же, если я соберу glibc 2.3.2, скачанную с gnu.org, какие проблемы > > > я могу получить? :) > > А ты соберешь? В RPM? > Почему в RPM? В исходниках. > То есть если я скомпилирую скачанную glibc, не будут ли у меня капризничать > альтовские пакеты из-за каких-то особенностей альтовской сборки? > > > Короче, может лучше скачаешь исходники своих софтин и соберешь с нашим > > glibc? > К сожалению, не получится, эти софтины в исходниках не распространяются :( > Хотя, если кто-нибудь посоветует пакет для видеомонтажа, наиболее похожий на > профессиональный, не требующий доустановки чего-то на ALM, буду весьма > благодарен и брошу затею с обновлением важных системных компонент не из > альтовских репозитариев :) Можете попробовать выкачать glibc 2.3.2 из Rawhide и поставить ее куда-нибудь в домашний каталог, затем запускать приложения, требующие glibc 2.3 вот таким образом: LD_LIBRARY_PATH=~/.lib/glibc ~/.lib/glibc/ld-2.3.2.so -- / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/