From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description of problem: When called from code that is statically linked, pthread_attr_setstacksize works. However, if the call is made from code that was dynamically linked, it has no effect. Version-Release number of selected component (if applicable): 2.3.2-95.20 How reproducible: Always Steps to Reproduce: 1. execute the run script in the attached tgz file Actual Results: cc -lpthread -o mainstatic main.c test.c cc -shared -o libtest.so test.c cc -lpthread -L. -ltest -o maindynamic main.c new thread used 1052672 bytes when test.o was statically linked new thread used 10489856 bytes when test.o was dynamically linked Expected Results: cc -lpthread -o mainstatic main.c test.c cc -shared -o libtest.so test.c cc -lpthread -L. -ltest -o maindynamic main.c new thread used 1052672 bytes when test.o was statically linked new thread used 1052672 bytes when test.o was dynamically linked Additional info: This bug seems to date back a ways. I was able to reproduce it on a redhat 7.1 machine. Another interesting note is that before the move to nptl, the default stack size was 8M if NULL was passed to pthread_create as the pthread_attr_t *, but 2M if a freshly pthread_attr_init'ed pthread_attr_t was passed in.
Created attachment 101759 [details] test case
This is a bug in your Makefile, not in glibc. By not linking libtest.so against -lpthread, the function references there become non-versioned and thus at runtime pick the GLIBC_2.0 versions. glibc 2.0 pthread_attr_t did not contain the stacksize stuff at all, (the type was smaller than it is now) and thus pthread_create obviously can't use fields which did not exist in that type. If you link libtest.so against -lpthread (also I'd suggest to put -lXXX options at the end of the command lines rather than at the beginning, otherwise things might link incorrectly), it will work as expected.