Building guile on i486 on sfdk fails

[Tomin1]

Building guile for i486 with sfdk fails and I have been trying to figure it out myself but it seems a bit too big of a challenge. Building guile package with the instructions on README.md fails with this error:

checking whether libunistring was built with iconv support... no
configure: error: No iconv support.  Please recompile libunistring with iconv enabled.

config.log tells a little bit more about the issue:

configure:47723: ./conftest
./conftest: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory
configure:47723: $? = 127
configure: program exited with status 127

This is different from the issue I had with mb2 and it does not happen with arm targets. At this point I'm not sure if this is an issue with my packaging or if it's bug in the SDK. I'll comment later here an easier way to reproduce the same issue.

[Tomin1]

Minimal way to reproduce this error with SDK: Build libunistring:

wget https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.10.tar.gz
tar xf libunistring-0.9.10.tar.gz
cd libunistring-0.9.10/
sfdk -c target=SailfishOS-4.0.1.48-i486 --specfile ../patience-deck/rpm/misc/libunistring.spec build

Install that to target snapshot and try to build and run a small program (I'm using ~/etc/sources/RPMS as my output-prefix, yours may be different):

sfdk tools package-install SailfishOS-4.0.1.48-i486.default ~/etc/sources/RPMS/SailfishOS-4.0.1.48-i486/libunistring{,-devel}-0.9.10-8.i486.rpm
cat > test.c << EOF
#include <uniconv.h>
#include <unistring/iconveh.h>
int main (int argc, char *argv[])
{
    size_t result_size;
    return (NULL == u32_conv_from_encoding ("ASCII", iconveh_question_mark,
                "a", 1, NULL, NULL, &result_size));
}
EOF
sfdk -c target=SailfishOS-4.0.1.48-i486 build-shell
gcc -o test test.c -lunistring
./test

The code above was taken from the config.log I mentioned. This will throw this same error:

./test: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory

If I try the same thing on arm target, it just runs without complaints.

In my previous testing I found that if I do similar test with gc library (that I also bulit for guile) I get the same issue there and thus I think that anything coming outside Sailfish causes this issue, but only on i486 targets.

[Tomin1]

This SDK fix seems to help and I can now build guile for i486. However it seems that harbour build no longer works as libunistring gets built without iconv support. There is a workaround in harbour build script that should make the test for working iconv support in libunistring configure command work. Once I reverted that change I applied to SDK's sb2, harbour build worked again.

[Tomin1]

There was a typo in that workaround I linked. I thought I had fixed it already but apparently I didn't even read the line when I added the link to the previous comment. Well, that's what happens when you write a comment on midnight. I pushed a fix to that. However that still doesn't work for building libunistring for harbour builds.

This is how I applied the workaround to Sailfish SDK:

git clone git@github.com:sailfishos/scratchbox2.git
cd scratchbox2/
git format-patch 1327ea1f..d14b047a -- utils/sb2
docker ps
# Grab container id for SDK from the list and substitute it in the next command
docker cp ca17df5f5e0f:/usr/bin/sb2 sb2
patch -p2 sb2 < 0001-sb2-Fix-exec-policy-for-executables-under-SDK-worksp.patch
docker cp sb2 ca17df5f5e0f:/usr/bin/sb2

Verifying that the patch is applied: sfdk engine exec grep sbox_user_workspace /usr/bin/sb2 should print two lines that were added in the patch.

[Tomin1]

I also tried applying the other part of the patch, although I think it doesn't matter:

git format-patch 1327ea1f..d14b047a -- rule_lib/fs_rules/user_rules.lua
docker cp ca17df5f5e0f:/usr/share/scratchbox2/rule_lib/fs_rules/user_rules.lua user_rules.lua
patch -p3 user_rules.lua < 0001-sb2-Fix-exec-policy-for-executables-under-SDK-worksp.patch
docker cp user_rules.lua ca17df5f5e0f:/usr/share/scratchbox2/rule_lib/fs_rules/user_rules.lua

It didn't help.

This is the error in libunistring's config.log:

configure:15544: checking for working iconv
configure:15685: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -m32 -msse -msse2 -march=i686 -mfpmath=sse -mtune=generic -fno-omit-frame-pointer -fasynchronous-unwind-tables   conftest.c  >&5
configure:15685: $? = 0
configure:15685: ./conftest
configure:15685: $? = 16
configure: program exited with status 16

which means at least one of these tests failed (returned -1):

iconv_t cd1 = iconv_open ("UTF-8", "EUC-JP");
iconv_t cd2 = iconv_open ("UTF-8", "eucJP");
iconv_t cd3 = iconv_open ("UTF-8", "IBM-eucJP");
iconv_t cd4 = iconv_open ("utf8", "eucJP");

It doesn't really look all that important but IIRC if I try to patch out the test building guile will get stuck at some point.

EDIT: This is what happens if I try forcing it, I guess guile bumps into the same issue (and I have already added the same workaround there):

GEN      guile-procedures.texi
Uncaught exception:
Throw to key encoding-error with args ("scm_to_stringn" "cannot convert narrow string to output locale" 38 #f #f)

[Tomin1]

I did one more test now and it looks promising. It might be just that I didn't use export for LD_LIBRARY_PATH so any commands would not have been affected by the values.

[Tomin1]

i486 builds should now work with SDK 3.8.3 as long as you apply the patch to sb2 command in build-engine. Eventually an SDK update will include that change too, so until then arm builds will be more straightforward.

[Tomin1]

SDK 3.9 has been released and builds work with that without workarounds.