Originally posted by: bernardn

The libpath of python3 in the latest RPM from the AIX Toolbox is not set properly:

> dump -X64 -H /usr/bin/python3
...
0      .:/usr/include:/opt/freeware/include:/usr/lib/threads:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib64:/usr/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/pthread/ppc64:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/../../../pthread/ppc64:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/../../..:/usr/lib:/lib                                         
...

It looks like a bug since python has a clean libpath:

> dump -H /usr/bin/python
 ...
 0      /opt/freeware/lib:/usr/lib:/lib    
 ...

I think the correct libpath for python3 and probably python (python2) should start with /opt/freeware/lib/pthread to pick up the pthread version of libgcc_s.a. It is also desirable for C++ extensions built with -pthread since they need the pthread version of libstd++.a.

Having two sets of GCC run-time shared libraries, with the thread-unsafe set in the default directory (/opt/freeware/lib) does not make things easy for developers. Does anyone know the reason for this setup?

Thanks,
Bernard

Originally posted by: AyappanP

Thanks for reporting the issue. We will fix python3 in the next release.

And about having two sets of GCC run-time shared libraries, we need that. If there is pthread library available in default path, then there will be an extra overhead for non-thread applications and performance will get an impact because the pthread libraries will perform additional thread safe operations which are not required for those applications.

So developers need to use this AIX linker option "-Wl,-blibpath:/opt/freeware/lib/pthread:/opt/freeware/lib:/usr/lib" during compilation to set the loader path for pthread applications. 

Originally posted by: bernardn

Hi Ayappan,

Thank you for the feedback. It would be nice if you could put the RPM spec files in a GitHub repo to allow contributions from the community.

And about having two sets of GCC run-time shared libraries, we need that. If there is pthread library available in default path, then there will be an extra overhead for non-thread applications and performance will get an impact because the pthread libraries will perform additional thread safe operations which are not required for those applications.

These two sets of GCC runtime libraries (pthread and non-threaded) create multiple issues:

• the non-threaded set is in the main lib directory (/opt/freeware/lib) and as a result is used most of the time, often unintentionally. 
• the ABIs for the pthread and non-threaded set are most likely different, at least for C++ applications, and especially for C++ applications using exceptions. See --enable-thread and --enable-libstdcxx-threads in https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc%2B%2B/manual/manual/configure.html. So you should not substitute one set for the other: a C++ library/app built without -pthread should not use the pthread GCC runtime and a C++ library/app built with -pthread should definitely not use the non-threaded runtime.

It's obviously very error-prone. For example, python3 is built with -pthread but its libpath starts with /opt/freeware/lib64:/opt/freeware/lib, so it erroneously uses the non-threaded runtime.

The simplest would be to get rid of this non-threaded GCC runtime. GCC on Linux doesn't provide a "non threaded" runtime, and I think you should do the same for AIX.

For me, this non-threaded runtime looks like a throwback to when threads were new...more than 20 years ago. xlc did the same with xlc/xlc_r and xlC/xlC_r. But if you check xlclang/xlclang++, there is fortunately no _r version of these compilers and only one set of runtime libraries.

Best regards,
Bernard

Originally posted by: AyappanP

I agree that having two sets of GCC runtime libraries (pthread and non-threaded) will confuse developers. But it's the responsibility of the developers to make sure applications compiled with -pthread should always link to pthread GCC runtime and one without -pthread should always link to non-pthread GCC runtime. 

In this case. python3 clearly has a bug. We will fix it in the next release. 

AIX pthread unfortunately is heavy weight and not hidden.  Linux provides "weak" versions of all pthread symbols in non-pthread library. AIX does not. 

Because of it, normal applications (non-pthreaded) will get a performance hit. So we can't ignore non-pthread GCC runtime libraries. 

Originally posted by: bernardn

Hi Ayappan,

As of AIX 7.1, AIX system libraries like libc.a are thread-safe: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.genprogc/thread_safe_libraries.htm

On my AIX 7.2 system, libc_r.a is just a symbolic to libc.a. I guess the AIX team decided to take the performance hit for singled-threaded applications. Why not do the same for GCC?

Now, assuming we are stuck with these 2 GCC runtimes (pthread and non-threaded) for a while, what's the rule to set libpath correctly in a program?

If a program built with GCC links with libphread, then the first entry in its libpath should be /opt/freeware/lib/pthread? And if a program built with GCC does not link with libpthread, the first entry in the libpath should be /opt/freeware/lib?

However, if you check python, it links with libpthread and yet its libpath picks the non-threaded GCC runtime:

ldd /usr/bin/python

/usr/bin/python needs:

         /opt/freeware/lib/libpython2.7.so

         /opt/freeware/lib/libffi.a(libffi.so.6)

         /opt/freeware/lib/libncurses.so

         /opt/freeware/lib/libsqlite3.so

         /opt/freeware/lib/libstdc++.a(libstdc++.so.6)

         /opt/freeware/lib/libgcc_s.a(shr.o)

         /usr/lib/libc.a(shr.o)

         /usr/lib/librtl.a(shr.o)

         /usr/lib/libdl.a(shr.o)

         /usr/lib/libpthreads.a(shr_comm.o)

         /usr/lib/libpthreads.a(shr_xpg5.o)

         /usr/lib/libpthread.a(shr_xpg5.o)

         /unix

         /usr/lib/libcrypt.a(shr.o)

Is this another bug?

Best regards,

Bernard

Originally posted by: AyappanP

Yes, it's a bug. We have been building python2 & python3 only recently with GCC. So this would have been missed.

Originally posted by: bernardn

Hi Ayappan,

Thank you for confirming this bug in the AIX Toolbox python and python3 RPMs.

Unfortunately it looks like the same bug affects more tools such as:

ldd dbus-daemon

dbus-daemon needs:

         /usr/lib/libc.a(shr_64.o)

         /usr/lib/libpthread.a(shr_xpg5_64.o)

         /opt/freeware/lib64/libdbus-1.a(libdbus-1.so.3)

         /opt/freeware/lib64/libexpat.a(libexpat.so.1)

         /unix

         /usr/lib/libcrypt.a(shr_64.o)

         /opt/freeware/lib64/libgcc_s.a(shr.o)

 

dbus-daemon links with libpthread but its libpath picks the non-threaded libgcc_s.a instead of the pthread version.

Do you agree with the rule that "if a program built with GCC links with libphread, then the first entry in its libpath should be /opt/freeware/lib/pthread"? Or would you formulate this rule differently?

Thanks,
Bernard