Summary: | libtool: install: error: cannot install `libphp5.la' to a directory not ending in /var/tmp/portage/dev-lang/php-5.3.5/work/sapis-build/apache2/libs when emerging php | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | anomaly |
Component: | [OLD] Server | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | axiator, flameeyes, jmbsvicetto, patrickallaert |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
libphp5.la
build log |
Description
anomaly
2011-01-10 02:28:02 UTC
Attach full build log and the la file it's complaining about. Created attachment 259430 [details]
libphp5.la
Created attachment 259432 [details]
build log
I wonder if that error message is about getting over the command line size. Diego, is this a libtool limitation or is that .la file just "bogus"? Okay first of all I have to say that php in tinderbox is not building because of MySQL issues so I don't have a clue whether I can reproduce this or not, sorry :/ As for the error... libtool is designed not to allow installing a file in a path different from what it has been built against, if it sounds stupid, that's because it generally is. I think the best bet is making sure to override the libdir both during build and install, rather than just install. I doubt it's a size problem. libdir='/var/tmp/portage/dev-lang/php-5.3.5/work/sapis-build/apache2/libs' doesn't look quite right...then again, perhaps it is. I'd say try rebuilding your libtool - that part of install process, due to apache quirks, uses system copy. I don't know if that last comment was for me or not -- but reinstalling libtool did not make a difference. FYI, if I do the following: Edit /var/tmp/portage/dev-lang/php-5.3.5/work/sapis-build/apache2/libphp5.la and remove the libdir and relink_command lines Run /usr/lib/apache2/build/instdso.sh SH_LIBTOOL='/usr/bin/libtool' libphp5.la /var/tmp/portage/dev-lang/php-5.3.5/work/sapis/apache2//usr/lib/apache2/modules Run /usr/bin/libtool --finish ebuild /path/to/php-5.3.5.ebuild merge the build will finish and install OK -- it's just the two lines in that la file that kills it. Looks exactly the same as #266537 I do have the same problem with dev-lang/php-5.3.6: make -j3 INSTALL_ROOT=/var/tmp/portage/dev-lang/php-5.3.6/work/sapis/apache2/ install-sapi Installing PHP SAPI module: apache2handler /usr/lib/apache2/build/instdso.sh SH_LIBTOOL='/usr/bin/libtool' libphp5.la /var/tmp/portage/dev-lang/php-5.3.6/work/sapis/apache2//usr/lib/apache2/modules /usr/bin/libtool --mode=install cp libphp5.la /var/tmp/portage/dev-lang/php-5.3.6/work/sapis/apache2//usr/lib/apache2/modules/ libtool: install: error: cannot install `libphp5.la' to a directory not ending in /var/tmp/portage/dev-lang/php-5.3.6/work/sapis-build/apache2/libs apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 emake failed Does someone know how to solve this instead of having to manually modify the libphp5.la file? No progress so far? I must manually do the operations as anomaly@... mentioned earlier every time I must compile dev-lang/php. Sorry Patrick. I cannot reproduce this, and this does not seem to be a wide-spread issue so that makes it difficult for me to figure out exactly what is wrong. Hi Ole Markus, I perfectly understand that. May I provide you more useful info about my environment? Would you require an ssh access to my box for further investigation? I am eager to help as much as possible to fix that issue. Regards, Patrick I've traced this issue to your system putting relink_command in the .la file. The restrictions on $libdir apply only in this case, which is why Ole and myself haven't experienced this issue. I've yet to figure out why the command is missing in my (and probably Ole's) system. I'll let you know if I can figure this out completely. Ole: how'd you like a more drastic approach: don't run emake install-sapi at all? At this point I'm up for just skipping this step and proceed straight to src_install, where I'd just dolib.so libphp5.so from ${WORKDIR}/sapis-build/apache2/.libs - honestly I can't remember why we do the intermediate step with ${WORKDIR}/sapis, but that may be due to me being gone for so long. What do you think? I'll provide a patch + new eblits tomorrow when I'm not half asleep. (In reply to comment #15) > Ole: how'd you like a more drastic approach: don't run emake install-sapi at > all? > At this point I'm up for just skipping this step and proceed straight to > src_install, where I'd just dolib.so libphp5.so from > ${WORKDIR}/sapis-build/apache2/.libs - honestly I can't remember why we do the > intermediate step with ${WORKDIR}/sapis, but that may be due to me being gone > for so long. What do you think? I'll provide a patch + new eblits tomorrow when > I'm not half asleep. I have no idea why we do that step. You were the one who wrote that ;) But it seems to me like everything becomes more simple without it. Well, it's not exactly tomorrow but the patch has found it's way into the php overlay over at http://git.overlays.gentoo.org/gitweb/?p=proj/php.git Can you please all review/test it and tell me if it solves the bug w/o introducing new issues before i commit it to CVS? Btw the reason it took so long was me trying to figure out if I can make "make install-sapi" work in case the target will ever do something more than copying the lib around. But I simply gave up facing the libtool black art :| It looks good to me. How about bumping eblits versions and use it for 5.3.8 that should be out tomorrow? Then we can piggypack testing on the arch team doing security stabilisation. Or would it be too naughty to do this on a security release? Ah well, with me slacking^Winstalling another gentoo machine we seem to have missed the deadline anyway? Since it only affects the build process and the output /should/ be the same, I think we can safely push this to a later -rX release. Hi, Is there any progress to push this solution to everyone? Cheers. I finally applied the fixes from the overlay to php5.4.0beta2, refraining to touch stable packages for now. They will be updated if I'm sure I haven't broken something. Thanks for your patience! |