bug#25141: Compilation issue on AIX 7.1 and 64 bits

[Eric LeBlanc <cognefou@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

Hi,


Probably, but I won't count too much on 32 bits binary because we tried two RPM emacs packages, one from IBM website and the other from BULLFREEWARE website and they both ended with a "Segmentation Fault" with a core dump when we execute "emacs".


I also played with LDR_CNTRL variable without any success.


It seems that AIX 7.1 is very memory strict with 32 bits binaries and I'm sure that "unexec" is doing some memory dump to the final emacs binary that AIX 7.1 doesn't like.


That's why I'm tyring to compile in 64 bits.


For the moment, "temacs" in 64 bits works well but slow to start.  I'm stuck at 'unexaix' operation and I'm not an expert in XCOFF binary file.  I know that 'unexaix.c' isn't adapted for 64 bits binaries and I tried to make some modifications as I wrote earlier by enabling __XCOFF64__ in "unexaix.c" source code, without success since it generates a huge 4GB emacs binary, but I know I'm not so far to fix it.


Thank you


Eric



________________________________
From: Eli Zaretskii <eliz@gnu.org>
Sent: December 24, 2016 11:11 AM
To: Eric LeBlanc
Cc: 25141@debbugs.gnu.org
Subject: Re: Compilation issue on AIX 7.1 and 64 bits

> From: Eric LeBlanc <cognefou@hotmail.com>
> CC: "25141@debbugs.gnu.org" <25141@debbugs.gnu.org>
> Date: Sat, 24 Dec 2016 14:05:33 +0000
> Finding pointers to doc strings...
> Finding pointers to doc strings...done
> Dumping under the name emacs
> unexec: couldn't find ", " section
> Makefile:754: recipe for target 'bootstrap-emacs' failed

I guess there's a deeper problem with the 64-bit build on AIX.

> ./temacs --batch --load loadup bootstrap
> exec(): 0509-036 Cannot load program ./temacs because of the following errors:
> 0509-130 Symbol resolution failed for /opt/freeware/lib/libgmodule-2.0.a(libgmodule-2.0.so.0) because:
> 0509-136 Symbol __dbargs (number 13) is not exported from
> dependent module /opt/freeware/lib/libglib-2.0.a(libglib-2.0.so.0).
> 0509-136 Symbol __dbsubc (number 14) is not exported from

This sounds like some system configuration problem?  Are you sure the
dynamic linker is picking up the same Glib library whose header files
the compiler saw?  Do you have another Glib shared libraries installed
somewhere?

[-- Attachment #2: Type: text/html, Size: 3486 bytes --]