Thread: Linux: directory change .../lib to .../lib64
Hello, Below the top level directory (--prefix) the lib directory changed with version 14.x now from .../lib to .../lib64: ls -ld /usr/local/sisis-pap/pgsql-*/li* drwxr-xr-x 1 root root 2754 19. Jul 09:58 /usr/local/sisis-pap/pgsql-13.3/lib drwxr-xr-x 1 root root 1594 19. Okt 10:36 /usr/local/sisis-pap/pgsql-14.0/lib64 drwxr-xr-x 1 root root 2810 29. Nov 10:59 /usr/local/sisis-pap/pgsql-14.1/lib64 This would mean changes of LD_LIBRARY_PATH of our servers using the PostgreSQL server with ESQL/C interface (libecpg.so.6). Why this change was made? For a future 128-bit Linux? I will see if I can overwrite this with: ./configure --prefix=/usr/local/sisis-pap/pgsql-14.1 \ --libdir=/usr/local/sisis-pap/pgsql-14.1/lib ... Btw: the help of ./configure says wrong things about the default: ./configure --help | egrep 'libdir=|prefix=' --prefix=PREFIX install architecture-independent files in PREFIX --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX for instance `--prefix=$HOME'. --libdir=DIR object code libraries [EPREFIX/lib] Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Matthias Apitz <guru@unixarea.de> writes: > Below the top level directory (--prefix) the lib directory changed with > version 14.x now from .../lib to .../lib64: > ls -ld /usr/local/sisis-pap/pgsql-*/li* > drwxr-xr-x 1 root root 2754 19. Jul 09:58 /usr/local/sisis-pap/pgsql-13.3/lib > drwxr-xr-x 1 root root 1594 19. Okt 10:36 /usr/local/sisis-pap/pgsql-14.0/lib64 > drwxr-xr-x 1 root root 2810 29. Nov 10:59 /usr/local/sisis-pap/pgsql-14.1/lib64 > This would mean changes of LD_LIBRARY_PATH of our servers using the > PostgreSQL server with ESQL/C interface (libecpg.so.6). Why this change > was made? You'd have to talk to the packager of whatever distribution you're using. No such change was made in the core PG code: the configure script still defaults to LIBDIR=EPREFIX/lib. regards, tom lane
El día Mittwoch, Dezember 01, 2021 a las 08:11:34 -0500, Tom Lane escribió: > Matthias Apitz <guru@unixarea.de> writes: > > Below the top level directory (--prefix) the lib directory changed with > > version 14.x now from .../lib to .../lib64: > > > ls -ld /usr/local/sisis-pap/pgsql-*/li* > > drwxr-xr-x 1 root root 2754 19. Jul 09:58 /usr/local/sisis-pap/pgsql-13.3/lib > > drwxr-xr-x 1 root root 1594 19. Okt 10:36 /usr/local/sisis-pap/pgsql-14.0/lib64 > > drwxr-xr-x 1 root root 2810 29. Nov 10:59 /usr/local/sisis-pap/pgsql-14.1/lib64 > > > This would mean changes of LD_LIBRARY_PATH of our servers using the > > PostgreSQL server with ESQL/C interface (libecpg.so.6). Why this change > > was made? > > You'd have to talk to the packager of whatever distribution you're using. > No such change was made in the core PG code: the configure script still > defaults to LIBDIR=EPREFIX/lib. It's me who is the packager. I compiled from source and the used configure run is: #!/bin/sh cd ~sisis/mpi-V73/postgresql-14.1 || exit export LDFLAGS="-L/usr/local/sisis-pap/lib -L/usr/lib64" export CFLAGS="-m64 -I/usr/local/sisis-pap/include" export CPPFLAGS="-m64 -I/usr/local/sisis-pap/include" ./configure --prefix=/usr/local/sisis-pap/pgsql-14.1 \ --enable-nls \ --with-perl \ --with-ldap \ --with-pam \ --with-openssl echo now run \'make world\' and as root \'make install-world\' And this brings the shared libs to /usr/local/sisis-pap/pgsql-14.1/lib64 Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
El día Mittwoch, Dezember 01, 2021 a las 08:11:34 -0500, Tom Lane escribió: > Matthias Apitz <guru@unixarea.de> writes: > > Below the top level directory (--prefix) the lib directory changed with > > version 14.x now from .../lib to .../lib64: > > > ls -ld /usr/local/sisis-pap/pgsql-*/li* > > drwxr-xr-x 1 root root 2754 19. Jul 09:58 /usr/local/sisis-pap/pgsql-13.3/lib > > drwxr-xr-x 1 root root 1594 19. Okt 10:36 /usr/local/sisis-pap/pgsql-14.0/lib64 > > drwxr-xr-x 1 root root 2810 29. Nov 10:59 /usr/local/sisis-pap/pgsql-14.1/lib64 > > > This would mean changes of LD_LIBRARY_PATH of our servers using the > > PostgreSQL server with ESQL/C interface (libecpg.so.6). Why this change > > was made? From the file config.log: ... configure:2687: loading site script /usr/share/site/x86_64-unknown-linux-gnu | #!/bin/sh | # Site script for configure. It is resourced via $CONFIG_SITE environment varaible. | | # If user did not specify libdir, guess the correct target: | # Use lib64 for 64 bit bi-arch targets, keep the default for the rest. | if test "$libdir" = '${exec_prefix}/lib' ; then ... -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
On 12/1/21 8:14 AM, Matthias Apitz wrote: [snip] > From the file config.log: > ... > configure:2687: loading site script /usr/share/site/x86_64-unknown-linux-gnu > | #!/bin/sh > | # Site script for configure. It is resourced via $CONFIG_SITE environment varaible. > | > | # If user did not specify libdir, guess the correct target: > | # Use lib64 for 64 bit bi-arch targets, keep the default for the rest. > | if test "$libdir" = '${exec_prefix}/lib' ; then > ... Is bi-arch really still relevant in 2021 (almost 2022)? -- Angular momentum makes the world go 'round.
Matthias Apitz <guru@unixarea.de> writes: > configure:2687: loading site script /usr/share/site/x86_64-unknown-linux-gnu > | #!/bin/sh > | # Site script for configure. It is resourced via $CONFIG_SITE environment varaible. > | > | # If user did not specify libdir, guess the correct target: > | # Use lib64 for 64 bit bi-arch targets, keep the default for the rest. > | if test "$libdir" = '${exec_prefix}/lib' ; then > ... Well, Autoconf's provision for site-local scripts is very ancient. I say again that this isn't anything we've changed: either that file wasn't there last time you did this, or its contents changed underneath you. regards, tom lane