Unable to link pluto when cross-compiling for m68k processor

[josephmartin09]

Hello, it is awesome that the latest Openswan release allows for a no mmu environment. I am having trouble tracking down the real source of the following error, which I get after trying to link pluto. If it is relevant, the SDK I'm using is only on gcc 4.4.

The error:

LD pluto /home/lantronix/linuxsdk/toolchains/freescale-coldfire-4.4/m68k-uclinux/bin/ld.real: -r and -shared may not be used together collect2: ld returned 1 exit status

Is there somewhere where I can disable shared library linking in favor of a statically linked library? I haven't tried upgrading my toolchain yet, but if you think that could help I will.

Thank you so much, Joe

[josephmartin09]

Turns out it was the security hardening fPIC/fPIE options that needed to be removed from certain make files these particular flags call -shared implicitly. Even if you get past this option, if you are building for a nommu architecture as I was, you are going to have to change the fork calls to vfork() to force the compile to run. I haven't gotten this to work yet for uclinux on a nommu 68k architecture, but maybe this will help someone

[mcr]

As well as changing fork=>vfork (will a #define do?) you'll want to force nhelpers=0, so do all the crypto in the foreground, as without an mmu, the subprocesses are not going to work right. Please expect some changes this year to better support embedded systems without resort to so many shell scripts.

[josephmartin09]

Define should work just as well. I believe I did it using a -Dfork=vfork option while cross compiling. If you have time, I was hoping you could provide some possible reasons as to why a malloc from msg_digest would fail. Malloc failed for 1908 bytes if anything connects to the UDP socket on port 500 and sends a packet (if i run ipsec on a host machine or even just from using netcat). I have tested being able to malloc this amount in a separate program as a sanity check. I definitely see that there is some fork() stuff without an execvp call going on in alloc.c, specifically alloc_bytes1, but so far I am unable to trace the true meaning of this error.

[letoams]

Even in older openswan there is already a define for this. There are some other work around for libc issues too Makefile.inc. libreswan's pluto already uses a --config option to remove all the shell script wrappers and parse config files itself.

Sent from my iPhone

On Jun 29, 2015, at 23:11, Michael Richardson notifications@github.com wrote:

As well as changing fork=>vfork (will a #define do?) you'll want to force nhelpers=0, so do all the crypto in the foreground, as without an mmu, the subprocesses are not going to work right. Please expect some changes this year to better support embedded systems without resort to so many shell scripts.

— Reply to this email directly or view it on GitHub.

[letoams]

See Makefile.inc (on libreswan but I thought openswan already had hose too) . Libreswan might have added code to avoid a malloc of 0, which glibc allows and ignores by many other c libraries error on

Sent from my iPhone

On Jun 29, 2015, at 23:25, josephmartin09 notifications@github.com wrote:

Define should work just as well. I believe I did it using a -Dfork=vfork option while cross compiling. If you have time, I was hoping you could provide some possible reasons as to why a malloc from msg_digest would fail. I get that malloc failed for 1908 bytes pretty if anything connects to the UDP socket on port 500 and sends a packet (if i run ipsec on a host machine or even just from using netcat). I have tested being able to malloc in a separate program as a sanity check. I definitely see that there is some fork() stuff without an execvp call going on in alloc.c, specifically alloc_bytes1, but so far I am unable to trace the true meaning of this error.

— Reply to this email directly or view it on GitHub.

[josephmartin09]

The define for vfork does exist within the code, however my experience was that it did not reach some of the lower fork calls, such as the one in alloc.c. I also see that in this file that if the alloc size is 0, it is manually hardcoded to be 1 byte to avoid malloc from returning null on uclibc.