[SOLVED] Problem with OpenCASCADE SBo on 64-13.1

ahmadj · 11-30-2010, 11:40 AM

Hi,

I'm trying to install OpenCASCADE via the slackbuilds.org script

The build runs fine, until a point, where it halts with the error: /usr/lib/libXext.so: could not read symbols: File in wrong format

ie. it is trying to use a the 32-bit libXext instead of the 64-bit one. I have checked the SlackBuild script and it seems to my eyes that the libraries are set correctly to use the libdirsuffix; indeed, all the libraries until this point in the compile are sourced correctly for /usr/lib64, so why is it looking in /usr/lib for this one? And how do I fix it?

I should also mention that I'm doing this through sbopkg as opposed to manually from console..

niels.horn · 12-01-2010, 03:58 AM

Hi,

Unfortunately I do not have a multilib system to test this for you.

Can you tell me at what point exactly it stops building?
It might be that some Makefile of some module looks at both /usr/lib and /usr/lib64.

I'm working on a new version of the SlackBuild for OpenCASCADE 6.4, but it is not very high on my priority list...

Niels

ahmadj · 12-01-2010, 05:05 AM

Thanks for the reply, Nils,

I'm unsure exactly how to pinpoint where the error occurs. I'm re-running the compile now and will attach a screenshot here once it fails.. would that help?

I wish to run the latest version (10.xx) of FreeCAD... do you know if I would need OpenCASCADE 6.4 for that, or would 6.3 be OK?

niels.horn · 12-01-2010, 05:12 AM

It would be best to paste the output of the build, to see where the error occurs. But a screenshot (as long as it shows the error) might help.

I tried FreeCAD 1.0x a while ago and it worked fine with OpenCASCADE 6.3.

Niels

ponce · 12-01-2010, 05:42 AM

FYI, tried (for fun

) to build it on -current multilib with sp9 instead of 6 and all went well.

but, if it's a link-time error, could be also that, on multilib, forcing LDFLAGS in a line before the CFLAGS' one in the slackbuild could do, like this

Code:

...
autoreconf -f -i

LDFLAGS="-L/usr/lib64 -L/lib64" \
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
...

ahmadj · 12-01-2010, 07:37 AM

Thank you both.

Here is a paste of the error:

Quote:

/tmp/SBo/OpenCASCADE6.3.0/ros/adm/make/TKMath/.libs/libTKMath.so /tmp/SBo/OpenCASCADE6.3.0/ros/adm/make/TKernel/.libs/libTKernel.so -ldl -lpthread -L/usr/lib64/gcc/x86_64-slackware-linux/4.4.4 -L/usr/lib/gcc/x86_64-slackware-linux/4.4.4 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../x86_64-slackware-linux/lib -L/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../.. /usr/lib64/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/crtendS.o /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../lib64/crtn.o -Wl,-soname -Wl,libTKXSDRAW-6.3.0.so -o .libs/libTKXSDRAW-6.3.0.so
/usr/lib/libXext.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libTKXSDRAW.la] Error 1
make[3]: Leaving directory `/tmp/SBo/OpenCASCADE6.3.0/ros/adm/make/TKXSDRAW'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/SBo/OpenCASCADE6.3.0/ros/adm/make'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/OpenCASCADE6.3.0/ros'
make: *** [all] Error 2

I will try out Ponce's suggestions...

ahmadj · 12-01-2010, 12:53 PM

Quote:

Originally Posted by ponce

but, if it's a link-time error, could be also that, on multilib, forcing LDFLAGS in a line before the CFLAGS' one in the slackbuild could do

This worked, thanks!

niels.horn · 12-01-2010, 01:06 PM

OK, I'll test this when I get home and - if it does not cause any problems on "standard" Slackware, I'll include it in the update for OCC 6.4.

Niels

ponce · 12-02-2010, 05:50 AM

this got into a bloodbath (at least for me, hope I am not too OT

): I've gone on building FreeCAD (and deps) on -current multilib and I stumbled in this while building FreeCAD itself

Code:

ld: cannot find -ljscore

I looked around a little and what I seem to have found is: if you run configure of qt-4.7.0 activating webkit, when you run make it actually builds libjscore.a and libjscore.prl, but the make install forgets about it and doesn't copy them in the $PKG folder.

(looks like there are other reports)
so I hacked qt.SlackBuild a little

Code:

@@ -184,6 +184,13 @@
   done
 )
 
+# seems make install forgot about these
+cp src/3rdparty/webkit/JavaScriptCore/release/libjscore.* $PKG/usr/lib${LIBDIRSUFFIX}/qt/lib
+
+# fix wrong hardcoded build paths in pkgconfig and *.prl files
+sed -i "s,$TMP/qt-$VERSION,/usr/lib${LIBDIRSUFFIX}/qt,g" $PKG/usr/lib${LIBDIRSUFFIX}/pkgconfig/*.pc
+sed -i "s,$TMP/qt-$VERSION,/usr/lib${LIBDIRSUFFIX}/qt,g" $PKG/usr/lib${LIBDIRSUFFIX}/qt/lib/*.prl
+
 # Add a documentation directory:
 mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION
 cp -a *GPL_EXCEPTION* FAQ* INSTALL KNOWN* LICENSE* README* changes-* \

(I spotted the second fix here)
and with the rebuilt qt he got its libjscore and was happy (for the moment).

But, as I am on multilib, another bugger arised: the linker refused to link /usr/lib64/../lib/libstdc++.so.

This is obvious, is a 32bit library, but I wasn't able to get where in his build configuration file was constructing this wrong path (that can happen if you don't know where to look :P )

I tried with the LDFLAGS trick but my ld-fu wasn't strong enough.

then I stumbled in this nice message and tried the LDEMULATION triple-kick, but it laughed at me.

as a last resort, I tried the second suggestion that Master Ken cite in the message above, and punched him indaface changing the linker

Code:

@@ -57,6 +58,7 @@
 
 ./autogen.sh
 
+LD='gcc ${BUILD64}' \
 CFLAGS="$SLKCFLAGS" \
 CXXFLAGS="$SLKCFLAGS" \
 ./configure \

and that fixed him for good

for the record, I was trying this later linker stuff with FreeCAD 0.10.3205 and had to do other modifications to the slackbuild (turned off debug too): result is a not-so-much working FreeCAD, because it cannot find any module (but I'll have a look on that too. It's like Terminator: you think you got him but he gets back on his feet

).

sorry for the long post but maybe it's useful to know about it.

P.S. happy note: after that qt fiddling, I made also a qt-4.7.1 (from the corresponding branch) package and is running nice on my desktop with alien's kde.

ppr:kut · 12-02-2010, 03:11 PM

Quote:

Originally Posted by niels.horn

OK, I'll test this when I get home and - if it does not cause any problems on "standard" Slackware, I'll include it in the update for OCC 6.4.

Niels

See http://www.slackbuilds.org/faq/#multilib

As long as it's only that simple LDFLAGS modification, it won't survive the review process

niels.horn · 12-02-2010, 03:52 PM

ppr:kut: OK...

I don't use multilib. I use "pure" 64-bits.
If something does not run on 64-bits means that it's badly written or it's a closed-source binary - and I want nothing to do with either.

ppr:kut · 12-02-2010, 04:37 PM

Well, not really. The LDFLAGS issue is quite common, and most likely affects quite some amount of scripts on SlackBuilds.org, hence the FAQ entry

The only things I tend to fix/report are if the script doesn't succeed with only multilib gcc/glibc installed, because 99% of the scripts do. But that's already pretty borderline stuff for SBo.

ahmadj · 12-03-2010, 05:13 AM

Very nice work, Ponce. I haven't got around to FreeCAD yet.. man that looks nightmarish.

May I ask whose Slackbuild you started off with for Qt 4.7? And how much extra work is it to get a working FreeCAD 10.xx?

ozanbaba · 12-03-2010, 05:32 AM

Lte me drop a link for SlackBuilds.Org FAQ for multilib systems:
http://www.slackbuilds.org/faq/#multilib

ponce · 12-03-2010, 06:57 AM

Quote:

Originally Posted by ahmadj

Very nice work, Ponce. I haven't got around to FreeCAD yet.. man that looks nightmarish.

yes, but without trying to do it I wouldn't have found that qt thingie

Quote:

May I ask whose Slackbuild you started off with for Qt 4.7? And how much extra work is it to get a working FreeCAD 10.xx?

for qt you can use the standard one (adding that "cp src..." as shown in the patch above)

if you want to try 4.7.1, as written in the slackbuild, it's using the kde-qt branches on gitorious, so

Code:

git clone git://gitorious.org/+kde-developers/qt/kde-qt.git
QTVER=4.7.1
cd kde-qt
git archive origin/$QTVER-patched > ../tmp.tar
git checkout origin/$QTVER-patched
QTCOMMIT=$( git log -1 | head -1 | cut -c 8-14 )
mkdir ../qt-${QTVER}_${QTCOMMIT}
cd ../qt-${QTVER}_${QTCOMMIT}
tar xf ../tmp.tar
cd ..
rm tmp.tar
tar Jcf qt-${QTVER}_${QTCOMMIT}.tar.xz qt-${QTVER}_${QTCOMMIT}

at the end you will have two folder, kde-qt and qt-4.7.1_somecommit, and a qt-4.7.1_somecommit.tar.xz: put this one in the qt build folder instead on the qt-4.7.0*.tar.xz and launch the build.

for the "working" freecad cannot tell yet cause here still cannot see its mods