Существуют ли конкретные определения Linuxthreads и NPTL

Question

У меня есть программа, которая должна работать по -другому для Linuxthreads и NPTL.

Существуют ли в этих LIBS, которые можно использовать в моей программе для обнаружения, используется ли NPTL или LinuxThreads?

Update1: Для выполнения выполнения есть GetConf Glibc_libpthreads, но что для времени компиляции?

Answer 1

Не похоже, что это возможно, вы можете изменить реализацию во время загрузки, поэтому невозможно узнать во время компиляции, независимо от того, что вы делаете.

На странице Pthreads Man:

В системах с GLIBC, который поддерживает как LinuxThreads, так и NPTL (т.е., GLIBC 2.3.x), переменная среды LD_ASSUME_KERNEL может использоваться для переопределения динамического выбора по умолчанию динамического линкера по умолчанию реализации потока. Эта переменная говорит динамическому линкеру, чтобы предположить, что она работает поверх определенной версии ядра. Указав версию ядра, которая не предоставляет поддержку, требуемой NPTL, мы можем заставить использование LinuxThreads. (Наиболее вероятная причина для этого - запустить (сломанное) приложение, которое зависит от некоторого неконформативного поведения в Linuxthreads.) Например:

bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                awk '{print $3}' ) | egrep -i 'threads|ntpl'
linuxthreads-0.10 by Xavier Leroy

Не говоря уже о том, что эти две реализации (в основном) бинарны совместимы, поэтому в основном вы не можете знать во время компиляции, какая библиотека потоков будет использоваться, когда -либо, потому что она может измениться в зависимости от переменных среды, присутствующих при запуске вашей программы, или кто -то может Скопируйте двоичный файл из системы NPTL в систему LinuxThreads. Вы просто не можете этого сделать, потому что это не то, что известно во время компиляции, по крайней мере, не так, как вы можете положиться.

Вам придется найти какой -нибудь способ использования обнаружения времени выполнения, или, может быть Возможно, чтобы использовать время выполнения, из которых используется Pthreads.

Другое возможное решение - добавить опцию в ваш сценарий настройки и сделать его выбирать человека.

Answer 2

Давайте сделаем шаг назад и спросим - почему вы хотите это сделать?

Существуют ли функции, которые один предоставляет, что нет? Если так, возможно, вы можете использовать dlsym на libpthread.so динамически запрашивать их существование во время выполнения.

Или это больше вопроса о каком -то поведении, которое отличается между ними, заставляя вашу программу плохо себя ведут? Если это так, я бы избежал полагаться на результаты такого поведения или проконсультироваться с такими стандартами, как POSIX, чтобы определить, что вы могу полагаться на. Часто такие ошибки переносимости представляют реальные недостатки в вашем коде, которые могут нуждаться в обращении даже к использованию библиотеки, которую вы считать работает". Когда параллелизм входит в картину, это особенно важно, чтобы получить право.

Наконец, если речь идет о размерах структур ... Также могут быть хакерские способы обойти это. Например (только пример, может быть полностью вне базовой, но иллюстрирует идею):

// Hack around difference in pthread_mutex_t
//
#define pthread_mutex_t pthread_mutex_t_linuxthreads
#include <some_linuxthreads_header.h>
#undef pthread_mutex_t
#define pthread_mutex_t pthread_mutex_t_ntpl
#include <some_ntpl_header.h>
#undef pthread_mutex_t

typedef union {
    pthread_mutex_t_linxthreads linuxthreads;
    pthread_mutex_t_ntpl ntpl;
} pthread_mutex_t;

Очень хакерский и очень уродливый, но просто бросая такие идеи в качестве возможного обходного пути ...

Answer 3

Просматривая заголовки, нет - нет никаких конкретных определений для NPTL против LinuxThreads.

Если вам это нужно определить, напишите небольшой скрипт, который создает файл заголовка, или передайте флаг определения компилятора. Вы можете получить информацию, анализируя вывод /lib/libc.so.6 (эта библиотека может быть запускаться в качестве обычного исполняемого файла). Я оставлю подробности вам, но вывод выглядит так:

Linuxthreads:

GNU C Library stable release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6 20060404 (Red Hat 3.4.6-11).
Compiled on a Linux 2.4.20 system on 2010-04-18.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        The C stubs add-on version 2.1.2.
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton
        GNU Libidn by Simon Josefsson
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
For bug reporting instructions, please see:
.

NPTL:

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-48).
Compiled on a Linux 2.6.9 system on 2010-10-25.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
.

(Тем не менее, постарайтесь скорее написать код, который не нуждается в этом.