Problem being that it tries to install libraries directly into /usr/lib64. The real reason is that this package has a large portion of self-written Makefile.in stuff. I propose using automake to generate Makefile.in, thus automatically adding DESTDIR-support, fixing the reported error. Proposed patches follow...
Created attachment 98313 [details, diff] Patch to the sources to add Makefile.am and change a section in configure.in
Created attachment 98314 [details, diff] Patch to the ebuild (run eautoreconf, use emake and make DESTDIR="${D}" install)
This is a rather intrusive change, I'd like to get the sci-team's approval before applying it.
Unfortunately I don't have an amd64 box and hence I can't test these. Since the patches look fairly extensive and libtecla is currently not keyworded for amd64 it might probably be better to send them upstream. Finally, I don't 100% understand what the problem really is. I assume you mean that the makefile installs the libraries into /usr/lib64 as opposed to ${D}/usr/lib64? The makefile from the source installs everything into $(LIBDIR) where on my box exec_prefix=${prefix} LIBDIR=${exec_prefix}/lib and hence the "make install prefix=${D}/usr" in the ebuild does the right thing. Hence, I don't presently see why this shoudn't work on amd64 (possibly with one or two additional sed's replacing "lib" with "$(get_libdir) ).
I can confirm the problem - this is indeed an access violation: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-dev-libs_-_libtecla-1.6.1-27708.log" open_wr: /usr/lib64/libtecla.a open_wr: /usr/lib64/libtecla_r.a open_wr: /usr/lib64/libtecla.so.1.6.1 symlink: /usr/lib64/libtecla.so symlink: /usr/lib64/libtecla.so.1 open_wr: /usr/lib64/libtecla_r.so.1.6.1 symlink: /usr/lib64/libtecla_r.so symlink: /usr/lib64/libtecla_r.so.1 and that the patch works. However this patch does not quite make much sense to me - it basically introduces the whole mechanism dealing with the generated libtecla.la - that is the library itself. What is so special about amd64 that this is necessary and how did it work on x86 then? I agree that the best course of action may be to send this issue and patches upstream. However if there is an urgent need to keyword this ~amd64 I think arch team can proceed with this fix too.. (Otherwise it can just stay in bugzilla while the upstream deals with the issue. It will be visible to those that need it on amd64.) George
I agree here.. please take the patches upstream (didn't see it wasn't even ~amd64 before)
(In reply to comment #4) > Finally, I don't 100% understand what the problem really is. I assume you mean > that the makefile installs the libraries into /usr/lib64 as opposed to > ${D}/usr/lib64? > The makefile from the source installs everything into $(LIBDIR) where on my box > > exec_prefix=${prefix} > LIBDIR=${exec_prefix}/lib The variables you mention are filled in at configure-time. On amd64, LIBDIR won't be ${exec_prefix}/lib (the default), but "/usr/lib64" as --libdir=/usr/lib64 is automatically given by calling econf. You do have the option of trying something like "make install LIBDIR=${prefix}/usr/$(get_libdir)", but to me this seems like another hack to force the makefiles into doing something they aren't meant to be capable of. I thought I'd handle bug #119477 + all the variable replacements given in the "make install" line in one go, and write a clean makefile. I agree this may seem an intrusive patch, and it is :) So feel free to add LIBDIR=${prefix}/usr/$(get_libdir), I've just tried it and it emerges fine as well... I just had this strange urge, and felt like following the guideline in the devmanual that says patching a Makefile that doesn't support DESTDIR is a good idea.
> The variables you mention are filled in at configure-time. On amd64, LIBDIR > won't be ${exec_prefix}/lib (the default), but "/usr/lib64" as > --libdir=/usr/lib64 is automatically given by calling econf. econf --libdir=\${exec_prefix}/$(get_libdir) would work it around then > You do have the option of trying something like "make install > LIBDIR=${prefix}/usr/$(get_libdir)", but to me this seems like another hack to > force the makefiles into doing something they aren't meant to be capable of. > I thought I'd handle bug #119477 + all the variable replacements given in the > "make install" line in one go, and write a clean makefile. > > I agree this may seem an intrusive patch, and it is :) So feel free to add > LIBDIR=${prefix}/usr/$(get_libdir), I've just tried it and it emerges fine as > well... I just had this strange urge, and felt like following the guideline It is, but it's nothing amd64 specific, so not really of our business :)
