Re: cannot install...to a directory not ending in
* Jeff Blaine wrote on Fri, Sep 22, 2006 at 11:26:07PM CEST: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. [...] 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 Try this: mkdir -p /blah/blah/usr ln -s /afs/blah/dest/sun4x_59/local/bison/1875 /blah/blah/usr/local make install DESTDIR=/blah/blah rm -r /blah/blah/usr Does that do what you want? Does your setup otherwise respect all the limitations I outlined in this message: http://lists.gnu.org/archive/html/libtool/2006-09/msg00066.html IOW: are there no deplibs of the to-be-installed programs and libraries that are not accessible through /usr/local/lib but only through /afs/blah/dest/sun4x_59/local/bison/1875/lib? If no, then the above sequence should be a decent workaround for the current restriction that at `make install' time, the string `$(DESTDIR)$(prefix)' has to end in the value of `$(prefix)' at `make' time. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
cannot install...to a directory not ending in
Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination This concept is used almost anywhere AFS/OpenAFS is used and anywhere there is a process in place to release software to its final destination. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? GCC 4.1.1 today: build:quake ../gcc-4.1.1/configure --prefix=/usr/rcf ... build:quake make bootstrap ... build:quake make install prefix=/afs/rcf/system/dest/lin24v2/local/gcc/040/ ... libtool: install: error: cannot install `libgij.la' to a directory not ending in /usr/rcf/lib ... ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
I believe the problem being described here is one that I have encountered also since I use stow for package management. A long time ago, it use to be the case you could say: ./configure --prefix=/dest make make prefix=/dest/stow/package-package version install even if the package installed shared objects. With more recent versions of libtool, I have had to add the --with-libdir=/dest/stow/package-package version/lib to allow proper installation. Ed Ralf Wildenhues wrote: Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
Hi Ralf and Ed, Ed's description of the problem is what I am experiencing. We use VECT (aka CMU's EMT Rewritten and made Lite) for release management of apps. Written by yours truly :) http://vect.sourceforge.net/ Anyway, it's the same problematic idea as Stow's. I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). We often gather up /dest in a tarball to drop onto non-networked machines, for example. They exist :) I bet building gcc (for example) with --with-libdir= is going to cause that. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. As for an appropriate solution (assuming --with-libdir doesn't turn out to be a royal pain to get going), I'd be happy with any environmental flag that would turn those 'fatal errors' into warnings. Edward Maros wrote: I believe the problem being described here is one that I have encountered also since I use stow for package management. A long time ago, it use to be the case you could say: ./configure --prefix=/dest make make prefix=/dest/stow/package-package version install even if the package installed shared objects. With more recent versions of libtool, I have had to add the --with-libdir=/dest/stow/package-package version/lib to allow proper installation. Ed Ralf Wildenhues wrote: Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
* Jeff Blaine wrote on Fri, Sep 22, 2006 at 06:30:42PM CEST: I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). Yes, in that case you probably may not do that. Note that unlike --libdir, --with-libdir is not standardized in any way, so I don't know what effect it would have on packages; in any case run paths to /dest/... are wrong. I ask you guys to please dig out an old package that uses (a probably older version of) libtool and that does not have this issue, and if you find one, point me to it. Only looking at it will allow me to decide whether there is a Libtool regression involved or not. Thank you. Other than that, please read this thread: http://lists.gnu.org/archive/html/libtool/2006-09/msg00062.html I've said most of what I think is to say on this topic there as of now. And I'm (slowly) working on improvement. Note that any usage case that is even the slightliest different than those I already know of, is important to look at, so if you think you have a setup I haven't covered there, by all means explain it to me (in detail), please. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. Using the DESTDIR approach I showed should get you going. If not then please come back and complain. Don't use the --with-libdir thingy if references to /dest/... are disallowed in the final installed files. And please note all the limitations I wrote about in the other thread. Unless I get more precise data I can only assume that older libtool versions just happened to work for some special cases; I don't think they worked for the general case where `prefix' was set differently at `make install' time. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. 2. /afs/blah/gamma/sun4x_59/local Our software repository for Solaris 9. It looks like any other common /usr/local tree. It has bin, lib, man, libexec, etc, and others. These directories are populated with whatever apps have been built and released so far. What you also need to know is that there is a step used to populate this area. That step gathers ALL of the item 1 above areas and folds them into a single /usr/local like item (/afs/blah/gamma/sun4x_59/local). 3. /usr/local A simple user interface to our software repository. It is a symlink to /afs/blah/gamma/sun4x_59/local I'm not in any way suggesting that you have changed something in libtool recently that has broken this. We have had trouble with it for a long long time. I think the use of libtool by apps is just starting to reach a final critical point for us and I'm forced to figure this out finally. I couldn't begin to tell you how I've fixed it before. If I had to guess, I bet I spent a half hour doing various things by hand. For now, I will have to use --with-libdir and give that a shot even though it is not workable for us in the medium-to-long run. I'll have to rebuild a bunch of things down the road if libtool is changed to work with the situation above, but I have no choice right now. I have apps that need to be built and released... last week. I don't see anything in the previous thread that addresses this. I don't mind being forced to run libtool with special options nowadays, if I have to, in order to get everything straightened out and happy. As it is, libtool *stops* me in my tracks by refusing to proceed because it doesn't like what I told it to do (make install prefix=/some/new/place). Please let me know if you need more information. Ralf Wildenhues wrote: * Jeff Blaine wrote on Fri, Sep 22, 2006 at 06:30:42PM CEST: I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). Yes, in that case you probably may not do that. Note that unlike --libdir, --with-libdir is not standardized in any way, so I don't know what effect it would have on packages; in any case run paths to /dest/... are wrong. I ask you guys to please dig out an old package that uses (a probably older version of) libtool and that does not have this issue, and if you find one, point me to it. Only looking at it will allow me to decide whether there is a Libtool regression involved or not. Thank you. Other than that, please read this thread: http://lists.gnu.org/archive/html/libtool/2006-09/msg00062.html I've said most of what I think is to say on this topic there as of now. And I'm (slowly) working on improvement. Note that any usage case that is even the slightliest different than those I already know of, is important to look at, so if you think you have a setup I haven't covered there, by all means explain it to me (in detail), please. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. Using the DESTDIR approach I showed should get you going. If not then please come back and complain. Don't use the --with-libdir thingy if references to /dest/... are disallowed in the final installed files. And please note all the limitations I wrote about in the other thread. Unless I get more precise data I can only assume that older libtool versions just happened to work for some special cases; I don't think they worked for the general case where `prefix' was set differently at `make install' time. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 04:52:27PM -0500, Albert Chin wrote: On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah Sorry, disregard this foolish suggestion. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
