<div dir="ltr">Hi Tony,<br><br>On Friday I was too quick to reply and among others I missed the part that you are from Bull. :) I used your R1502 version as the starting point. Still, let me add a few more hints. Mind you my memory can fail (I was working with AIX ~ 2 years ago). Hopefully the experts will correct me if I got something wrong. View it as my 2 cents. It is not comprehensive as you will realise it soon.<br><br>> “what are the main features that must be made available ?”<br><br>AIX users tend to be large banks and similar organisations, and I imagine many of them interested in running RabbitMQ. So, based on my limited knowledge on the matter if you can start RabbitMQ that might be good enough for many. To list the minimal features I would say that SMP, 64bit, SSL are very likely. Others readers might add theirs too.<br><br>HIPE:<br><br>Hipe is mainly a performance boost for some applications, but many Erlang use cases do not require it and as Mikael said you can ignore it for now. Linux is always there for people preferring performance over AIX features. :)<br><br>SMP:<br><br>On the other hand I would argue that enabling smp support is probably a must for most use cases and it is not too difficult to achieve. One of the issues is that the AIX provided Assembler does not support the local labels syntax of the GNU Assembler. So, one either experiments with the GNU Assembler or change the labels and jumps in erts/include/internal/ppc32/atomic.h. See [1] and [2].<br><br>One can replace the label “1:\t” with “L1%=:\t” and replace the corresponding jump “bne- 1b\n\t” with “bne- L1%=\n\t”. Of course use a different label each time (E.g. L1, L2, L3, ...) This might or might not have performance implications, but definitely better than not having SMP support.<br><br>Since Power8 offers up to 96 simultaneous threads, scheduler binding might be of interest of some potential users. To achieve that replace [3] and [4] with:<br><br>#include “sys/thread.h”<br>bindprocessor(BINDTHREAD, thread_self(), (cpu_t) cpu)<br>or something similar.<br><br>64 bit and compiler/linker flags:<br><br>OBJECT_MODE=64 env variable needs to be exported obviously.<br><br>GCC needs the following flags to link the executable: -Wl,-bexpall,-brtl,-b64 -maix64<br><br>For example you might have success bootstrapping by:<br><br>CFLAGS=“-maix64 -g -O2 -D_LINUX_SOURCE_COMPAT -L/opt/freeware/lib64 -L/opt/freeware/lib” \<br>LDFLAGS=“-Wl,-bexpall,-brtl,-b64,-blibpath:/opt/freeware/lib64:opt/freeware/lib -maix64” \<br>AR=“ar -X64” \<br>./otp_build autoconf --with-ssl=/opt/freeware --build=<name of your build> --disable-hipe<br><br>and then the same flags for running ./otp_build configure<br><br>Optionally you can also put the flags into the respective conf files. :)<div><br></div><div>Maybe some apps will not compile, like os_mon or odbc. Tip to proceed quickly: you can skip any app by placing an empty file called SKIP in their directory. (lib/*/SKIP)<br><br>OTHER:<br><br>Note that the C standard allows the malloc(0) system call to return either zero or a pointer that cannot be dereferenced. Unixes typically return a non-zero pointer, but AIX returns 0 by default. The C interface of Erlang (erl_interface) calls malloc(0) for empty strings and checks the return value against 0 to catch allocation errors. To prevent core dumps in such cases it helps to define -D_LINUX_SOURCE_COMPAT which enforces the non-zero pointer returns. Defining it will probably not hurt and  users of C drivers will appreciate.<br><br>As I mentioned R18 reworked clock/time handling. Expect some incompatibilities in that area.<br><br>The missing vsyslog on AIX can potentially be worked around by using printf. Or perhaps you know a better solution.<br><br>As openssl versions seems to go obsolete rather quickly, expect that many users will be interested not only in the binary but also in your source rpm package when you upload to BullFreeware, so they can potentially compile and link with a different openssl version.<br><br>BASIC TESTING:<br><br>To check if core/thread number detection works start the Erlang shell and note the smp information in the first line. It should match the number of CPU threads you have. For example [smp:8:8]. See [5]<br><br>Also note the presence of [64-bit] on the same line.<br><br>Bonus (may not be critical for many) if you can bind schedulers, for example: erl +sct L0-7c0-7 +stbt db +S8:8<br>then erlang:system_info(scheduler_bindings). returns {0,1,2,....}<br><br>and erlang:system_info(cpu_topology). returns<br>[{processor,[{core,{logical,0}},{core,{logical,1}},{core,{logical,2}}, ... }]}]<br><br>While in the shell issue crypto:start(). that should return ok if linking with ssl worked.<br><br>There are also test suites for the emulator. You can run ./otp_build setup with the above CFLAGS, AR, LDFLAGS, add your bin dir to the PATH and run ./otp_build tests. Change dir to release/tests/test_server, run erl, then ts:install(), ts:run(emulator, [batch]).<br><br>Take the above information with a grain of salt as I have no access to AIX and not an expert on building Erlang. The OTP team or others might correct my mistakes.<br><br>Thank you for your work!<br><br>Best regards,<br><br>Andras<br><br>[1] <a href="https://gcc.gnu.org/ml/gcc/2005-12/msg00671.html">https://gcc.gnu.org/ml/gcc/2005-12/msg00671.html</a><br>[2] <a href="http://stackoverflow.com/questions/3898435/labels-in-gcc-inline-assembly">http://stackoverflow.com/questions/3898435/labels-in-gcc-inline-assembly</a><br>[3] <a href="https://github.com/erlang/otp/blob/maint-19/erts/lib_src/common/erl_misc_utils.c#L591">https://github.com/erlang/otp/blob/maint-19/erts/lib_src/common/erl_misc_utils.c#L591</a><br>[4] <a href="https://github.com/erlang/otp/blob/maint-19/erts/configure.in#L2294">https://github.com/erlang/otp/blob/maint-19/erts/configure.in#L2294</a><br>[5] <a href="http://erlang.org/doc/man/erl.html">http://erlang.org/doc/man/erl.html</a><br></div></div>