Tests / linking errors on i386 and armhf

I am one of the maintainers of link-grammar source code.
I have never tried to compile it on 32-bit, but I will do it now and will fix these bugs.
Please feel free to report any link-grammar bugs in the GitHub link-grammar package repository at https://github.com/opencog/link-grammar and we will try to fix them in a timely manner.

UPDATE:
I have just pushed to the GitHub LG repository a pull request for all the fixes for i386 that also addresses the compilation warnings on Ubuntu 19.04.

I expect that it will be applied shortly (after it is reviewed).
I would appreciate it much if after that you could install LG on i386 from its GitHub repository and verify that all the problems you encountered are indeed solved.

I would also appreciate much a pointer to the the "original FTBFS" problems that you mentioned so I will be able to fix them if they are still present.

Later today I intend to look at the problems on armhf.

A new release with these fixes (and the needed ones - still unknown - for armhf) is expected in a few days.

Well, if it was a matter of never having been tested on 32-bits, that's something we can also address by removing the builds for 32-bits.

The specific errors are here; when running autopkgtests which try to rebuild the package and run unit tests:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/armhf/l/link-grammar/20190902_090536_925cc@/log.gz

Or simply here, at build time: https://launchpadlibrarian.net/438576953/buildlog_ubuntu-eoan-armhf.link-grammar_5.6.2-1ubuntu1_BUILDING.txt.gz

Specifically, the issues for armhf are with linking:
/bin/bash ../../libtool --tag=CXX --mode=link g++ -D_DEFAULT_SOURCE -std=c++11 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -O3 -Wall -version-info 11:2:6 -export-dynamic -no-undefined -export-symbols ./link-grammar-java.def -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o liblink-grammar-java.la -rpath /usr/lib/arm-linux-gnueabihf jni-client.lo ../../link-grammar/liblink-grammar.la -lhunspell-1.7 -lminisat -lm
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/arm-linux-gnueabihf/9/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/9/crtbeginS.o .libs/jni-client.o -Wl,-rpath -Wl,/<<PKGBUILDDIR>>/link-grammar/.libs -Wl,--as-needed ../../link-grammar/.libs/liblink-grammar.so -lhunspell-1.7 -lminisat -L/usr/lib/gcc/arm-linux-gnueabihf/9 -L/usr/lib/gcc/arm-linux-gnueabihf/9/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/9/../../../../lib -L/lib/arm-linux-gnueabihf -L/lib/../lib -L/usr/lib/arm-linux-gnueabihf -L/usr/lib/../lib -L/usr/lib/gcc/arm-linux-gnueabihf/9/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabihf/9/crtendS.o /usr/lib/gcc/arm-linux-gnueabihf/9/../../../arm-linux-gnueabihf/crtn.o -g -O2 -fstack-protector-strong -O3 -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,liblink-grammar-java.so.5 -Wl,-retain-symbols-file -Wl,./link-grammar-java.def -o .libs/liblink-grammar-java.so.5.6.2
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 7362 >= 3462 for section `.strtab'
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 17702 >= 3462 for section `.strtab'
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 4297 >= 3462 for section `.strtab'
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 11253 >= 3462 for section `.strtab'
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 14316 >= 3462 for section `.strtab'
/usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 19556 >= 3462 for section `.strtab'
[...]

I'm happy to drop the i386 and armhf architectures from the package though, if that's the best solution.

> Well, if it was a matter of never having been tested on 32-bits, that's something we can also address by removing the builds for 32-bits.

I have fixed the 32-bits bug that caused the bad tests.
I also fixed all the compilation warnings on i386 and armhf.

By now all of these fixes have been applied to the link-grammar repository and I expect a new release in a few days.

> Specifically, the issues for armhf are with linking:
> ...
> /usr/bin/ld: ../../link-grammar/.libs/liblink-grammar.so: invalid string offset 7362 >= 3462 for section `.strtab'

These warnings are not related specifically to link-grammar. They happen in some other packages for armhf and embedded processors. People suggest that the default segment for strings is too small for some embedded processors, or that there is a toolchain problem. I don't know which is correct, if any. I guess it will now work find even with these linkage warnings (I still need to install an armhf guest machine to test it.)

Please see for example::
https://bugzilla.samba.org/show_bug.cgi?id=13754 (samba on armhf)
https://stackoverflow.com/questions/45501504/ld-invalid-string-offset-for-section-strtab
https://www.google.com/search?q="ld"+"invalid+string+offset"+"section+strtab" (ggogle search)

All of these problems are totally unrelated to Python and SQLite, so there is no need to block them.

Summary:
The problems related to the library itself have been fixed.
Please don't remove link-grammar from i386 and armhf.
Just build it again from the upcoming release.
The blocking from Python and SQLite can be release just now as there is no reason here for them.

UPDATE:
A new release of link-grammar (5.7.0) has just been released.
It includes the said bug fix (see #4) for 32-bit.
It also includes compilation warning fixes (all was harmless).

The test suite passes fine now. Please use it instead of 5.6.2.
If you encounter a bug, or a packaging problem that is due to a problem in the source code, please open an issue on GitHub (see #1 for a link) and I will try to provide a fix in a timely manner.

@amirpli Armhf autopkgtest started passing so I believe this issue is solved. Thank you for caring about 32 architectures, too.