SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So that's two of us and an imaginary cat against Synapticifation.
I'd rather sbopkg development focus on stability and core features rather than fancy fangled GUIs. However, since sbopkg can be controlled with CL switches there is no reason why a GUI frontend could not be made as a separate project. That would keep the development clean for sbopkg.
I'd rather sbopkg development focus on stability and core features rather than fancy fangled GUIs. However, since sbopkg can be controlled with CL switches there is no reason why a GUI frontend could not be made as a separate project. That would keep the development clean for sbopkg.
Yeah, if somebody wants to do that - OK. But the present text-based UI seems quite satisfactory to me (and an assorted collection of domestic and farmyard animals ).
/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.
I got this fixed when I figured out that plib was the culprit. A re-build of plib solved the Bad value problem. Actually, I wasn't really wanting to build torcs-1.3.1, but torcs-1.3.0. I tried the newer version because I couldn't do the older one.
After fixing plib, I re-visited 1.3.0, got past the bad value, then encountered other problems. 1.3.0 won't compile on gcc-4x without a patch. I could not find the patch I had, so I had to manually edit 4 .cpp files. I got past that and ran into some stuff that said it was undefined in trajectory.o. I popped back into 1.3.1, and borrowed a few lines of code and inserted them into 1.3.0. That worked and now torcs-1.3.0 is running very well on Slackware64-current.
I am not a programmer or code genius, and this is way off-topic, but I had to say I finally had success. I just wish I had wrote it all down along the way.
Update: Sbopkg 0.30.0beta has been released. From the ML announcement:
Quote:
Thanks to everyone that has tested sbopkg0.30.0alpha1! Based on that
feedback, and some further testing of our own, we are now releasing a
beta of 0.30.0. In addition to various bug fixes, here are some of
enhancements and improvements since the alpha release:
* Add option to retry a failed build. Thanks to Zordrak for suggesting this
feature.
* Add CLEANUP configuration variable, which when set to YES tells sbopkg to
delete the extracted sources, and all the associated "residuals" of the
build, as soon as the build is finished. Thanks to Marco Bonetti and
Gregory Tourte for the suggestion and the nice discussion.
* Add a function to delete obsolete (not installed) packages from $OUTPUT.
Thanks to alkos333 for the idea.
* Reorganize the queue editing functions a bit for a better user interface;
'view queue' now only shows the queue; new 'sort' and 'remove' queue menu
items now handle the editing functions; thanks to Pierre Cazenave for the
suggestion.
Please note that we've set Slackware 13.0 as the 'default' Slackware
version even though obviously 13.0 has not been released yet. Just
change the setting in sbopkg.conf back to 12.2 and you should be good to
do. We're just gettin' prepared. :-) Speaking of sbopkg.conf, there
is now one new variable 'CLEANUP' so you may want to check
sbopkg.conf.new and migrate the change over to your own config file.
As always, please feel free to post feedback on the sbopkg mailing list
or in #sbopkg on irc.freenode.net.
Here are direct links to a package and source tarball of
sbopkg-0.30.0beta:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.