You are not logged in.
Hi all !
I am trying to build a package (for openmotif 2.2.3 as lib32...) but while it is fine manually (./configure && make), I obtain a different result with the commands in a PKGBUILD with makepkg.
The error I obtain (during make) is:
...
In file included from /usr/include/X11/Xos.h:146:0,
from makestrs.c:51:
/usr/include/X11/Xarch.h:49:31: fatal error: machine/endian.h: No such file or directory
# include <machine/endian.h>
^
compilation terminated.
Makefile:157: recipe for target 'makestrs.o' failed
make[2]: *** [makestrs.o] Error 1
...It seems to be because when "/usr/include/X11/Xarch.h" is evaluated, "CSRG_BASED" is defined instead of "linux". And a lot of results for the configure checks are differents too (for example "dlfcn.h" or "malloc.h" which are found in the first case and not in the second...).
Does anybody see what could be the problem ?
Thanks
Last edited by Le_J (2014-02-11 21:00:18)
Offline
manual ./configure uses the environment of your normal user, while makepkg runs in a special environment, search for fakeroot if you want to know more.
There is a package https://aur.archlinux.org/packages/lib32-openmotif/ in AUR for 2.3.4 , but that just seems to copy i686 binaries to /usr/lib32 .
pleaase post your PKGBUILD and the complete output of makepkg (likely a lot of text, you may want to use a pastebin site).
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Here they go:
PKGBUILD: http://pastebin.com/XEcY4igj
Makepkg: http://pastebin.com/38pw5LfA
begin of configure --prefix=/usr && make: http://pastebin.com/jYufwTDq
Strangely, it also works fine when I do a makechrootpkg and I think it don't get the same environment as the user, isn't it ?
It also fails if the configure step is done by makepkg and make by hand.
I'll also give a try to the i686 binaries copy but I would like to know what is the problem anyway...
Thanks a lot.
Offline
I'm thinking the problem is here: checking how to run the C preprocessor... /lib/cpp
Not sure why it's doing that, though. When you build in a chroot, does that give you gcc -E or /lib/cpp?
Do you even have /lib/cpp (or /usr/lib/cpp) on your system?
Last edited by Scimmia (2014-02-11 18:56:01)
Offline
Yes, the same in chroot:
checking how to run the C preprocessor... /lib/cppIndeed, I don't have such a file... neither in real root nor chroot.
Last edited by Le_J (2014-02-11 19:26:02)
Offline
can we get a log of the configure in the chroot, then?
I just tested it and I get the same failure in a clean chroot, so your logs could reveal something different.
Last edited by Scimmia (2014-02-11 19:20:38)
Offline
Ok, so now it is strange... It does not compile anymore in chroot while I have just created a 32bits package.
In fact, I now think that I got the package creation in x86_64 working once and then it always failed thereafter. Thus the error could be due to the fact that I got the compilation right to the end once. But I don't really see why.
EDIT: Ok, so if you get this error too, it can't be the problem...
Last edited by Le_J (2014-02-11 19:25:00)
Offline
If I add unset CPPFLAGS to the PKGBUILD, it works. Its value in PKGBUILD is this:
CPPFLAGS=-D_FORTIFY_SOURCE=2Do you see why this could make the compilation fail ?
Offline
I'm guessing it's because their build system is so old. The configure script was generated with autoconf 2.13, which was released in Jan 1999. I tried an autoreconf, but it failed (which I expected).
Offline
Here is a discussion that matches the problem:
http://lists.gnu.org/archive/html/autoc … 00003.html
Maybe you could do something like this?
function build() {
cd $srcdir/openMotif-$pkgver
(
# subshell for all steps which fail with _FORTIFY_SOURCE
export CPPFLAGS="${CPPFLAGS/-D_FORTIFY_SOURCE=2/}"
# ./autogen.sh
./configure --prefix=/usr
)
make
}Last edited by progandy (2014-02-11 20:51:42)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Yes, I think so.
So thanks a lot and this is solved as I managed to compile it with makepkg.
However, my goal was to use this library to make Libero work (http://www.microsemi.com/products/fpga- … libero-ide) but it seems to fail in the same way with this version... So I'll go the Wine way for the time being...
Offline
You can always modify your makepkg.conf: Either move _FORTIFY_SOURCE to CFLAGS and CXXFLAGS or add -O2 to CPPFLAGS. Then it works again, even if it is not a semantically clean solution.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Ok, but I don't understand why it fails because I have no knowledge in autoconf.
Why isn't FORTIFY_SOURCE already in CFLAGS and CXXFLAGS ? This is only an option for C++ but the old autoconf just use CPPFLAGS and CFLAGS randomly ? Is the failure due to a mismatch ?
Offline
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks you all for the threads and your help. I now exactly understand what was going on. I hope I wasn't too rude in my previous posts.
I have successfully used both solutions (add -O2 to CPPFLAGS or move FORTIFY to CFLAGS and CXXFLAGS) to build the i686 and x86_64 packages. I then made the lib32 package by copying the lib directory of the i686 package. Finally, I managed to start the linux version of Libero by using this blog post after installing the lib32 package:
http://rainexperiment.wordpress.com/201 … -luck-yet/.
Last edited by Le_J (2014-02-12 19:11:16)
Offline