What changes must be made in a slackBuild from 11.x To build for Slackware64 current?
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.
What changes must be made in a slackBuild from 11.x To build for Slackware64 current?
Hi Forum
There are lots of packages which have mot yet been ported to Slackware64 13 or <current>,
Things like scilab, suitesparse, hdf5, Gnumeric...
In such Slackbuilds, there is a variable that controls the target architecture of the build, which is ARCH...
There are also other settings which default to a standard install in versions of Slackware for 32 bits like /usr/lib instead of /usr/lib64...
My question is... :
Is it reasonable to hack the slackbuild so as to conform to the standards of Slackware64 <currrent>, or are there much deeper incompatibilities than just the ones I pointed out...?
I am refering to standalone libraries and applications, not development packages like Python or gcc... in short...
I am refering to stuff that *DOES NOT EXIST* in Slackware64 <current>... whatever vesion...
The number "64" is parametrized in modern SlackBuild scripts by using the variable $LIBDIRSUFFIX which gets the empty value or "64" depending on the architecture (as determined by the ARCH variable).
That is why you see this - and if the old SlackBuilds do not not have this block, then add it:
Code:
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
So, for stuff like I refered to... Libraries, standalone applications, there should be no problem in building the packages, and installing them in SL64...?
Nice...
I just do not understand How Paraview dropped stuff into /usr/lib..
"It is said that two Tigers cannot live in the same Mountain"...
I remember someone in this forum saying the two versions of Python can coexist in the same computer, the libraries and shared objects install to different folders... "python" is only a symlink to the active version in the system...
So I ask, in case i do all the preparation you instructed me to, regarding the Salckbuild for Python 2.5.2, is it safe to install the created package in a freshly installed Slackware...?
It was I who said that in another post.
You can install 2.5 and 2.6 versions alongside, and the second package will overwrite the /usr/bin/python and some other symlinks, as well as a few binaries, also in /usr/bin.
If you primarily care for the python libs but want the invocation of "python" to start /usr/bin/python2.6 then I would suggest to act as follows: build and install a 64-bit version of python 2.5 on top of your Slackware64 system. Then restore the overwritten parts of python2.6 by finding the original Slackware python2.6 package on your DVD and running
Code:
upgradepkg --reinstall python-2.6.4-x86_64-1.txz
After that, you should still have a fully operational Slackware, and have python2.5 added on top, and programs looking specifically for it would find it.
I would be very interested if that will indeed work out well for you. If not, it may be needed to pass explicit python flags to your SlackBuild scripts that need this.
So this means that when specifically invoking python2.5 in bash ( to run a compilation script which calls for Python2.5 )
I would run something like #/usr/..../python2.5/python myPythonScript.py, and it would find its way to Py 2.5 components despite the fact that #python -V would report 2.6.x ( the active symlink in /usr/bin pointing to Py2.6.x ) ?
Cool...
I ask this because I am about to format, install SL64 13, upggarde to <current>, and rebuild most of my stuff...
BRGDS
Alex
BTW: I kept all my slackbuild tarballs in an external HDD, just in case my packages were trashy, which happened to be, at least for some of them...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.