Well, the build failed. It ended with this:

/usr/lib64/gcc/x86_64-slackware-linux/4.3.3/../../../../x86_64-slackware-linux/bin/ld: /usr/lib64/libplibssg.a(ssg.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/libplibssg.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libclient.so] Error 1
make[4]: Leaving directory `/tmp/SBo/torcs-1.3.1/src/libs/client'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory `/tmp/SBo/torcs-1.3.1/src/libs'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/tmp/SBo/torcs-1.3.1/src'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/tmp/SBo/torcs-1.3.1'
make: *** [restart] Error 2

I have tried passing -fPIC on other builds as well - they all seem to fail with this same error. I have not had much luck on googling either, but this would be fodder for another thread.

... me and my cat Sparky

I don't really have a cat, but if I had, it would be against that idea.

It looks like perhaps one of the things you built has not yet been updated for Slackware64. Not all the scripts have yet, and SlackBuilds.org of course does not yet officially support Slackware64 (since Slackware64 has not been released yet). I see you were building torcs -- I will try that now on a pretty clean slackware64 install.

Also, if the SBo SlackBuild has been updated for Slackware64, then you should not have to do that since that is set in the SlackBuild in this block:

if [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
SLKCFLAGS="-O2 -march=i686 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
fi

Everything built and installed fine on my Slackware64-current system using sbopkg 0.30.0alpha1:

++++++++++++++++++++++++++++++++++++++++++
PACKAGE BUILDING/INSTALLATION SUMMARY LOG
Using the SBo repository for Slackware 12.2
Queue process: build and install

OpenAL:
MD5SUM check passed.
Built package: OpenAL-1.7.411-x86_64-1_SBo.tgz
Installed package: OpenAL-1.7.411-x86_64-1_SBo.tgz

plib:
MD5SUM check passed.
Built package: plib-1.8.5-x86_64-1_SBo.tgz
Installed package: plib-1.8.5-x86_64-1_SBo.tgz

freealut:
MD5SUM check passed.
Built package: freealut-1.1.0-x86_64-1_SBo.tgz
Installed package: freealut-1.1.0-x86_64-1_SBo.tgz

torcs:
MD5SUM check passed.
Built package: torcs-1.3.1-x86_64-1_SBo.tgz
Installed package: torcs-1.3.1-x86_64-1_SBo.tgz

++++++++++++++++++++++++++++++++++++++++++

##########################################
Queue process complete
##########################################

So that's two of us and an imaginary cat against Synapticifation.

Apart from sycamorex and his imaginary cat, you can count me in too.

Me, my wife and kids, and my dog, duck, 15 chickens and 3 pigs too.

samac

I think we're winning.

Hold your horses, Brian. Woodman might have already propagated this crazy idea among all wood creatures

Yup, the bears are on my side.

Okay, let's stop hijacking Chess's thread!

I'm going to use AlienBob's script and mirror the tree again. I am using the first release with all updates. I may have borked something along the way. Maybe in a config script or something. Who knows?

Well, it ran through gnucash on slamd64 12.2 useing the SlackBuild 12.2 repo.
The only pkg I had to do manually was gnome-vfs.
I then installed them on Slack64 and everything worked perfect!

THANKS Chess!

There are a *lot* of things that simply won't work without modification on Slackware64-current. The changes (in most cases) are not difficult at all -- they're usually trivial -- but they take a *lot* of time to make (and then test the resulting build) when you take into account that there are almost 2000 scripts in the SBo repository. Last time I looked, about 400 have been confirmed as good on Slackware64 (no, they're not public, and they won't be until 13.0 is out, so don't ask), and we're steadily working through more of them, but there's pretty much no way we'll be able to knock out all of them before 13.0 releases.

Before someone asks, no, we're not soliciting volunteers for testing or anything along those lines. While offers would be (are) certainly appreciated, we intend to keep the admin team small, and in the interest of maintaining a "chain of trust," we're going to personally test anything that goes into the "good for 13.0" batch.

Cool -- did you use the gnucash.sqf file:

http://sbopkg.org/queues/12.2/

or did you manually put together the list?