On Wed, Mar 5, 2025 at 11:43 AM Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden <jklow...@schemamania.org> > wrote: > > > > On Tue, 4 Mar 2025 00:08:16 +0100 > > Jakub Jelinek <ja...@redhat.com> wrote: > > > > > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote: > > > > However IMO, the incantation: > > > > > > > > make install DESTDIR=/foo > > > > > > > > is invalid. The compiler's library search path is fixed when the > > > > compiler is built, based on configure options. Installing into an > > > > arbitrary directory cannot work; there is no opportunity then to > > > > alter the gcobol binary. > > > > > > This is how most distros install stuff for their packaging systems, > > > make install DESTDIR=/some/directory > > > and then everything under /some/directory > > > is packaged into the package. > > > GCC is generally relocatable, the compiler driver should find the > > > compiler and library/include directories etc. relative to where the > > > driver resides in the filesystem. > > > > Thank you for taking the time to explain that, Jakub. I stand > > corrected, and I believe you'll find that DESTDIR works as intended > > using the current cobol-patched branch. It works here for me. > > > > Somehow, despite reading the automake documentation over and over > > these last several days while we struggled to bring the libgcobol > > build process into the 20th [sic] century, I didn't put 2 + 2 together. > > Looking at it now, I see that by using automake we get DESTDIR for free, > > provided (as we do) that we use libtool for installation. > > > > In short, despite not trying to support DESTDIR, we do anyway, by happy > > accident. And we are now better informed. > > Thanks. Checking cobol-patched again I see > > obj2> make install DESTDIR=/home/rguenther/install/gcc-cobol > ... > libtool: install: /usr/bin/install -c .libs/libgcobol.so.1.0.0T > /usr/local/lib64/../lib64/libgcobol.so.1.0.0 > /usr/bin/install: cannot create regular file > '/usr/local/lib64/../lib64/libgcobol.so.1.0.0': Permission denied > make[2]: *** [Makefile:956: install] Error 1 > make[2]: Leaving directory > '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol' > make[1]: *** [Makefile:18349: install-target-libgcobol] Error 2 > make[1]: Leaving directory '/home/rguenther/obj2' > make: *** [Makefile:2671: install] Error 2 > > so a DESTDIR install isn't quite working yet. > > install: libgcobol$(libsuffix).la > $(LIBTOOL) --mode=install $(INSTALL) $^ $(libdir)/../lib64 > > the usual way would be to have automake/libtool generate the install rule by > only doing > > toolexeclib_LTLIBRARIES = libgcobol.la > > you have > > lib_LTLIBRARIES = libgcobol.la > > so simply removing the install: rule might work (there's toolexeeclib vs. lib, > this might or might not mean --enable-version-specific-runtime-libs will > break). > > [time passes] > > So dropping the install rule makes make install succeed but there's no > libgcobol installed. I have the wrong automake on the test machine so > can't quickly check what happens when using toolexeclib_LTLIBRARIES
So I now checked and using toolexeclib_LTLIBRARIES = libgcobol.la works: > find install/gcc-cobol/ -name libgcobol* install/gcc-cobol/usr/local/lib64/libgcobol.la install/gcc-cobol/usr/local/lib64/libgcobol.so.1 install/gcc-cobol/usr/local/lib64/libgcobol.a install/gcc-cobol/usr/local/lib64/libgcobol.so.1.0.0 install/gcc-cobol/usr/local/lib64/libgcobol.so and the installed compiler behaves as intended. I can trick -m32 to "work" by using the generic gcc diriver: > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c but I think this is a less important issue. Richard. > > > > Regards, > > > > --jkl
