Slackware 14.2; nettle and/or gmp libraries (as packaged) have problems in software builds ?
 

I'm trying to build LibreOffice 4.3.7.2 on Slackware 14.2/amd64.

Well into the build, I'm getting the situation when one of the LO's dynamic libraries can't be loaded, because one of GMP libraries symbol can't be found; in this case the GMP library is referenced by the NETTLE library (both in distro, both present). This is the msg:

[build CUT] vcl_app_test
DynamicLibraryManagerException: "Failed to load dynamic library: /d/home/ty/c/libo/libreoffice-4.3.7.2/workdir/LinkTarget/CppunitTest/libtest_vcl_app_test.so
/usr/lib64/libhogweed.so.4: undefined symbol: __gmpn_cnd_sub_n"

The libtest_vcl_app_test.so has references to libgmp.so.10 (where this symbol is actually defined) and to libhogweed.so.4 (which references libgmp.so.10) -- and it's the libhogweed.so.4 loading that fails. I'm not a specialist in this, but it looks like libhogweed is loaded before libgmp ?

Now, in the /usr/lib64 (and in nettle-3.2-x86_64-1 package) there's no libhogweed.la file, which, AFAIU should facilitate such dependencies loading. Could this be the cause?

I've created a simple one by hand and am rebuilding the LO. Will get back in a couple of hours, hehe. Meanwhile, advise on this is welcome.

can you please paste more of the msg? it might also be an underlinking error...

sorry for the curiosity, is there a specific reason why you are building an old libreoffice version?

I'm doing the complete rebuild after the .la file creation (by hand), but don't have that dir processed yet.

But essentially what's been posted is what I get there - "can't load DLL because can't see the symbol" (while both the symbol and the DLL reference are actually there). Hence the question.

No need to be sorry, the version number was there exactly for the purpose of raising the awareness. ))

So, the 4.3 is the last LO series which both 1) is not a resource hog and feels snappy on reasonably modern hardware (amd athlon x2 5000 and 4G RAM) and 2) has no issues with certain big/complicated documents, which, as I'm told by developers, I'd essentially have to debug/fix by myself.

In a word, 4.3 works (with my big documents), 5.2 doesn't.

However, the 4.3 as downloaded from libreoffice.org produces crashes on Slackware 14.2 on several operations (like clicking the 'About' or starting the soffice w/o parameters). So it seems like I'd have to re-build.

And now I have those silly problems with building (which appeared precisely after migration to slackware 14.2 release from 14.1 and 14.2betas).

Well, the build just aborted. And no, no luck with the .la file being present. The message in its entirety follows:

[build CUT] vcl_app_test
DynamicLibraryManagerException: "Failed to load dynamic library: /d/home/ty/c/libo/libreoffice-4.3.7.2/workdir/LinkTarget/CppunitTest/libtest_vcl_app_test.so
/usr/lib64/libhogweed.so.4: undefined symbol: __gmpn_cnd_sub_n"
Path is '.:/d/home/ty/c/libo/libreoffice-4.3.7.2/solenv/bin:/home/ty/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/share/ant/bin:/usr/lib64/kde4/libexec:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/qt/bin:/usr/share/texmf/bin'

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE # for exception catching
export CPPUNITTRACE="gdb --args" # for interactive debugging on Linux
export CPPUNITTRACE=""[full path to devenv.exe]" /debugexe" # for interactive debugging in Visual Studio
export VALGRIND=memcheck # for memory checking

and retry using: make CppunitTest_vcl_app_test

/d/home/ty/c/libo/libreoffice-4.3.7.2/solenv/gbuild/CppunitTest.mk:70: recipe for target '/d/home/ty/c/libo/libreoffice-4.3.7.2/workdir/CppunitTest/vcl_app_test.test' failed
make[1]: *** [/d/home/ty/c/libo/libreoffice-4.3.7.2/workdir/CppunitTest/vcl_app_test.test] Error 1

you can do what the script says but, IMHO, it doesn't make much sense.
libreoffice is a bitch to build: is there any reason why you are not using an existing SlackBuild for it? masochism? :)

I've spotted one for what seems to be the last version of the 4.x serie between Alien Bob's ones (found it looking here) and it looks pretty complex, I don't think it's useful to anybody (surely not me) going again through the same path of pain he probably crossed writing that

http://bear.alienbase.nl/mirrors/peo...e44.SlackBuild

in its various versions there are often referrals to unit test just failing that get patched out, maybe yours is one of them, I sincerely have no idea.

check also the directory in which the SlackBuild is contained for the files referred in it...

ah, I have also no idea if that SlackBuild is still supported, it can be it isn't anymore (it would seem reasonable to me).

That was uncalled for.

I've been able to build my local instance of LO (earlier, OOo) for years now (fixed building on FreeBSD 4 series, actually), with no more trouble than attuning the configure options. One configure run, one make run, couple of hours grinding, no more problem until the next version needing building.

(And it's the downloading and packaging stage that take up so much space in Eric's script (above 50% I guess). I've done without native OOO packages for years)

I believe the 'workflow' of my local 4.3.7.2 build has no inherent problems by itself, as it worked okay in 14.2beta (I guess), and definitely worked un 14.1, it's just that NETTLE now depends on GPM (it didn't yet in February 14.2beta), which throws off the loading. And I just can't spare the time at the moment to learn the LO makefiles hierarchy.

it was just a joke, no offense meant...
I'm sorry, I wish I could help you, but I have no idea why it broke: I was only saying that breaking is normal if you keep using a not-anymore-supported source tarball of LO, you simply have to get used to it more and more while things keep moving on.
if I were you, I would try to find a supported version/fork or you will, most probably, spend a lot your time looking for patches.

No problemo.
Just wanted to put things into the correct perspective ))

As to what I shall/could do...

As the very last resort, I can always go back to 14.2beta, which sits on the neighbouring partition, and where the 4.3.7.2 works perfectly ))). Processing of those big docs takes an absolute precedence.

Still would appreciate a sensible advise on that problem, though.

I've returned to the issue, and now can say that that IS a slackware 14.2 packaging/building problem.
It is, or is not limited to the CUPS library linking case.
Now, there is no libcups.la in 14.2, but even if one is created by hand, the attempt to link with '-lcups' fails.

Proof:
1) create the simpliest of .C sources, in my case:
int main()
{
return 0;
}
2) try to create an executable linking with libcups.so, in my case:
gcc -o test test.c -lcups
3) both with libcups.la (of trivial content), or w/o it, get linking error, w/r to the GMP symbols referenced by libhogweed.so, which library is itself referenced by libnettle:
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpz_limbs_write'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpz_limbs_finish'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpz_roinit_n'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpz_limbs_modify'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpn_cnd_sub_n'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpz_limbs_read'
/usr/lib64/libhogweed.so.4: undefined reference to `__gmpn_cnd_add_n'
collect2: error: ld returned 1 exit status

4) If one uses the following command linem, though...

gcc -o test test.c -lgmp -lcups

...everything works okay.

***
The dlpreopen keyword in .la file seems to do not what I've thought it does. Need to use something else there. Or need I?

No, didn't succeed yet. Only the failure point seems to be now not the libcups.so itself, but the libgnutls.so (linked from there), itself linking to libnettle.so and further to libhogweed.so (which is the actual linking instance producing errors referring to libgmp.so symbols).

So my guess is the solution would be to re-compile the libnettle (or libgnutls?), with some additional libtool flags?

Help, help. Pretty please.

I don't see those errors here:

Well, do you have the slackware64-14.2 installed on your system (like in my case), or is it the -current?
Also, I have some extra packages installed, but nothing intruding upon the 'core' slackware, I believe.

Yes, Slackware64-14.2

My Slackware64 14.2 system (installed fresh, not an upgrade from 14.1) also runs that code fine.

Have you tried a VM with a fresh install to see if it is working fine there? Did you do a full or partial install? Was this a fresh install or an upgrade from 14.1 or -current?

First thing, thanks for your attention guys, bassmadrigal and chris.willing.

Did just that, from the same ISO, too. Install was full in both cases. And yes, in VM it works okay.

However, it gets more interesting: every other login user on machine, i.e. root and guest (just created, actually), can do the `gcc -o test test.c -lcups` on said source, producing the executable.

It's only my login account that fails the `gcc -o test test.c -lcups`, but is okay with `gcc -o test test.c -lgmp -lcups`.

Now, what could I have in my homedir causing such behaviour?? Must run now.

Okay, solved. Talk about being silly. Had LD_LIBRARY_PATH setting in my .profile pointing, among other things, to the ancient instance of libgmp. Works okay now. Thanks to all concerned )).