Description
Describe the bug
If an operating system has two libraries with the same name (libintl for example) on different paths, say in path "A," which is the default, and the other in path "B," then how can we make it use the library on another path "B" in this case?
Even if we try to give the absolute path (harcode the path) to the library present in path "A," since the Meson build system uses the Wnoipath option, the entire path will be erased and only the library name will be used to link. My understanding is that Meson uses this option because Meson uses relative paths to link libraries or binaries during compile time.
One example of a command is pasted below.
gcc -o glib/gtester glib/gtester.p/gtester.c.o -Wl,-bernotok -Wl,-bnoipath -Wl,-bbigtoc -maix64 -O2 -fsigned-char -mcmodel=large -maix64 -O2 -fsigned-char -Wl,-blibpath:/home/buildusr/rpmbuild/BUILD/glib-2.76.3/64bit/aix/glib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib glib/libglib-2.0.a -lintl
Another example is (I have cut the command since it was long)
gcc -o glib/libglib-2.0.so.0 glib/libglib-2.0.so.0.p/deprecated_gallocator.c.o glib/libglib-2.0.so.0.p/deprecated_gcache.c.o glib/libglib-2.0.so----------------------------------.0.so.0.p/gspawn.c.o glib/libglib-2.0.so.0.p/giounix.c.o glib/libglib-2.0.so.0.p/gthread-posix.c.o -Wl,-bernotok -Wl,-bnoipath -Wl,-bbigtoc -shared -fPIC -maix64 -O2 -fsigned-char -mcmodel=large -maix64 -O2 -fsigned-char -Wl,-blibpath:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib glib/libcharset/libcharset.a -liconv -lintl -lm /opt/freeware/lib/libpcre2-8.a -pthread
Meson does not want glib/libglib-2.0.so.0 to come in the PATH section of the binary. It only want libglib-2.0.so.0 to come.
As a consequence of this, let us say we build a library using Meson that links to libintl, which is present in paths "A" that it should not link to and "B" which it should link to even though one has given the absolute path to libintl that the library must link to. If this library is used from path "A," the libintl present here does not have certain symbols, or the shared library (.so file) required in the archive when compared to the libintl.a present in path "B,". Hence the application will crash with symbol not found or shared object not found since it links to libintl present in path "A". One sample error is as follows:.
/usr/lib/libiconv.a(libiconv.so.2)
ar: 0707-109 Member name libiconv.so.2 does not exist.
dump: /tmp/tmpdir29294964/extract/libiconv.so.2: 0654-106 Cannot open the specified file.
/opt/freeware/lib/libpcre2-8.a(libpcre2-8.so.0)
/usr/lib/libmls.a(shr.o)
But had we given the absolute path like "B"/libintl things will work.
One example is glib2 and libintl library linking in path /usr/lib which is AIX native libintl instead of the open source libintl present in /opt/freeware/lib.
Kindly note that we use a noipath option that erases the path to the library and retains only the library name in the binary.
To Reproduce
Build glib2 in AIX and run any application that uses the glib library from /usr/lib.
Expected behavior
The glib2 library should have linked to the open source libintl present in the /opt/freeware/lib path, but it links to the /usr/lib libintl when run from /usr/lib, that is AIX's native libintl and does not have symbols needed by glib2.
So there are scenarios where we want to give the absolute library path.
So I want to understand how we can solve this issue or use a absolute library path to come in binary so that it can link to the correct library when built with meson. Is there a way? Kindly let me know from your knowledge on how we can solve this issue.