Hi Michael,
On 21/04/2021 16:23, Michael Tremer wrote:
Hello,
I have a (similar?) patch here:
https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=48dfb9059e...
You can just cherry-pick that one, too.
Yes it looks like the one I got from the qemu github. That patch worked and qemu built.
Now it has stopped at strace. It looks like it is not possible to now enable m32 personality support.
checking for m32 personality compile support (using gcc -I./bundled/linux/arch/x86/include/uapi -I./bundled/linux/include/uapi -Isrc -m32)... yes checking for m32 personality runtime support... no checking whether mpers.sh m32 -m32 works... mpers-m32/sample_struct.d2: index [ ] without special no checking whether to enable m32 personality support... no configure: error: Cannot enable m32 personality support make: *** [strace:81: /usr/src/log/strace-5.11] Error 1
The default configure for strace is yes for m32 support and for several years strace enforces mpers support by default.
It looks like I can use --disable-mpers or --enable-mpers=check to overcome that. Before I do that I would just like confirmation that this is okay to do or if there is a way to get m32 runtime support on IPFire if it is needed. As it is related to 32 bit I could imagine that it will not be needed after the end of this year anyway
Regards, Adolf
-Michael
On 21 Apr 2021, at 14:57, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
I have found a patch in the qemu github which is named
0004-build-no-pie-is-no-functional-linker-flag.patch
and the description seems very similar if not exact to what I am getting. It mentions an update of binutils triggering the problem. This is from back in Dec 2020.
I will try this patch out in my build and let you know how things go.
Regards,
Adolf.
On 21/04/2021 15:42, Adolf Belka wrote:
Hi Marcel,
On 21/04/2021 07:43, Marcel Lorenz wrote:
Hi Addolf,
look here: https://git.ipfire.org/?p=people/mlorenz/ipfire-2.x.git;a=commitdiff;h=a5376...
Thanks for the patch information. One of those patches was the one I had already got from Michael. I added the other patch into my build but got the same result. Hyperscan builds fine but qemu fails. The same errors have occurred, the first one being
BUILD multiboot.img ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) make[3]: *** [Makefile:57: multiboot.img] Error 1
and the second
make[2]: *** [Makefile:206: pc-bios/optionrom/all] Error 2 make[2]: *** Waiting for unfinished jobs....
Full log for qemu from this build attached.
Regards, Adolf.
Regards,
Marcel
Am 20.4.2021 19:30, schrieb Adolf Belka:
Hi Michael,
On 19/04/2021 11:55, Michael Tremer wrote:
Hello,
Yes it is.
I ran into this in my toolchain branch where I am collecting updates for all sorts of tools related to this.
You can cherry-pick the following commit and hyperscan builds again:
https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=32a72d4ca8...
I used the patch from the above commit and it solved the hyperscan problem but then I next hit qemu failing to build. It seems to be doing things around meson even though the lfs is defined with autotools and both can be used. Attached is the log file for the qemu build. I can see the error in the logfile but I can't figure out what is causing the error to occur and therefore can't figure out how to stop it.
Any suggestions gladly welcomed.
Regards,
Adolf. -Michael
On 17 Apr 2021, at 21:53, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
It definitely is related to the new binutils in some way. Doing a git restore to the current binutils and redoing the clean and make results in hyperscan building without any problems.
Regards,
Adolf
On 17/04/2021 16:11, Adolf Belka wrote: Hi All,
I was building an update of binutils. That built successfully but then hyperscan had a lot of failures. I am not able to understand what the problem is from the error messages.
Could this be related to my update of binutils?
If yes then what do I need to change?
If no then what is causing the problem?
I did a git pull origin next before I did my build of binutils.
Error log attached.
Regards,
Adolf.