RE: [suse-programming-e] linux Threads vs. NPTL
I realy don't understand How you could check this at run time since the program will NOT even LOAD to start running if you are linked agaist the NPTL and it isn't available via the LD_LIBRARY_PATH specified when you start the program. Your program will just fail to start with an error message about not being abe to find a symbol. Now if you specify LAZY_BINDING your program will start up, but will crash when you try to access this service. Personally I find LAZY_BINDING a pain because I don't find out until 3 hours into my program that somehting didn't load right. I guess the real question you need to ask yourself is... what is your program going to do if that symbol isn't available? Does your program function properly without that service? If you program can live without it why did you need it in the first place? Typically for Dynamic checking of library services you can not use them by name in your code because of the above problems. The best you can do is to reference them via FUNCTION POINTERS that You yourself calculate at runtime. You open the library you want try to resolve symbols in figure out the address of that function assign it to a function pointer. If that function doesn't exist set your pointer to null. Then in your code you specify if ( pthread_tryjoin_np_ptr != NULL ) /* function exists */ (*pthread_tryjoin_np_ptr) (params) else ??????? But again like I said....What does your progam do on the ELSE side? -----Original Message----- From: Jerry Feldman [mailto:gaf@blu.org] Sent: Friday, March 04, 2005 8:37 AM To: suse-programming-e@suse.com Subject: Re: [suse-programming-e] linux Threads vs. NPTL On Friday 04 March 2005 10:51 am, Dimych wrote:
I had understood your point :) When saying "...that will prevent a program from linking with the Linux Threads library..." what exact errors are you getting? I though it's possible to link your programm against both those libraries at the same time. There are some functions that exist in NPTL and not in Linux Threads. If you compile using only the Linux Threads libary (eg. /usr/lib/libpthread.so), and you code uses the function, pthread_tryjoin_np(), it will fail to link.
What I am really looking for is a way to detect at run time, if the code has been linked with the nptl library or not. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e
On Friday 04 March 2005 1:21 pm, Calkins, Dennis wrote:
I realy don't understand How you could check this at run time since the program will NOT even LOAD to start running if you are linked agaist the NPTL and it isn't available via the LD_LIBRARY_PATH specified when you start the program.
Your program will just fail to start with an error message about not being abe to find a symbol.
Now if you specify LAZY_BINDING your program will start up, but will crash when you try to access this service. Personally I find LAZY_BINDING a pain because I don't find out until 3 hours into my program that somehting didn't load right.
I guess the real question you need to ask yourself is...
what is your program going to do if that symbol isn't available? Does your program function properly without that service? If you program can live without it why did you need it in the first place?
Typically for Dynamic checking of library services you can not use them by name in your code because of the above problems.
The best you can do is to reference them via FUNCTION POINTERS that You yourself calculate at runtime.
You open the library you want try to resolve symbols in figure out the address of that function assign it to a function pointer. If that function doesn't exist set your pointer to null.
Then in your code you specify
if ( pthread_tryjoin_np_ptr != NULL ) /* function exists */ (*pthread_tryjoin_np_ptr) (params) else ???????
But again like I said....What does your progam do on the ELSE side?
-----Original Message----- From: Jerry Feldman [mailto:gaf@blu.org] Sent: Friday, March 04, 2005 8:37 AM To: suse-programming-e@suse.com Subject: Re: [suse-programming-e] linux Threads vs. NPTL
On Friday 04 March 2005 10:51 am, Dimych wrote:
I had understood your point :) When saying "...that will prevent a program from linking with the Linux Threads library..." what exact errors are you getting? I though it's possible to link your programm against both those libraries at the same time.
There are some functions that exist in NPTL and not in Linux Threads. If you compile using only the Linux Threads libary (eg. /usr/lib/libpthread.so), and you code uses the function, pthread_tryjoin_np(), it will fail to link.
What I am really looking for is a way to detect at run time, if the code has been linked with the nptl library or not. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e
More specifically, let's say that my program is going to deploy on several systems, but I want to make sure that the target system has nptl. Example, I just built a simple threaded app on a SuSE 9.2 system with a 2.6.11 kernel. Since NPLT and Linux Threads are binary compatible, a simple threaded app will work on a non-NPTL system. Your solution, above, should work. As far as the else side goes, I might just want to abort. one possible reason for doing this is that my code may be using features in nptl, such as signals where I want rely on the semantics of nptl. Or possibly I want to test my pid. On a non-nptl system, each thread has a unique PID, where on nptl each thread will have the same pid. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
[Could you please edit your quotes? It makes reading much easier] Jerry Feldman <gaf@blu.org> [Fri, 4 Mar 2005 13:57:46 -0500]:
one possible reason for doing this is that my code may be using features in nptl, such as signals where I want rely on the semantics of nptl. Or possibly I want to test my pid. On a non-nptl system, each thread has a unique PID, where on nptl each thread will have the same pid.
I understand what you're trying to achieve, but it isn't really feasible. The only way to do what you want would be to dynamically load libpthread via dlopen(3) and then using dlsym(3) to check if NPTL specific symbols (functions,variables etc.) are available. But then you would need to access *every* symbol in libpthread through pointers that your code would have to set up. Now given that glibc is also involved as it contains weak symbols that are replaced by those of libpthread to make things in glibc thread safe in case it's needed and that wouldn't happen if you dlopened libpthread, it's bound to get very messy. I'd provide two binaries plus a frontend that does the dlopen stuff to determine which one of those is needed and exec that. Philipp
On Friday 04 March 2005 2:24 pm, Philipp Thomas wrote:
I understand what you're trying to achieve, but it isn't really feasible. The only way to do what you want would be to dynamically load libpthread via dlopen(3) and then using dlsym(3) to check if NPTL specific symbols (functions,variables etc.) are available. But then you would need to access *every* symbol in libpthread through pointers that your code would have to set up. Ok, thanks for the hints. I don't think that it's worth it to do. While this is not exactly what I was looking for, it might accomplish most of what I was looking for: Using the confstr(3) function, pass _CS_GNU_LIBPTHREAD_VERSION as an argument. This is analogous to the command line: getconf GNU_LIBPTHREAD_VERSION if it returns successfully, then it will return a string that contains something like NPTL 0.61 if nptl is installed on the system. -- Jerry Feldman <gerald.feldman@hp.com> Partner Technology Access Center (contractor) (PTAC-MA) Hewlett-Packard Co. 550 King Street LKG2a-X2 Littleton, Ma. 01460 (978)506-5243
participants (4)
-
Calkins, Dennis -
Jerry Feldman -
Jerry Feldman -
Philipp Thomas