LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   What changes must be made in a slackBuild from 11.x To build for Slackware64 current? (http://www.linuxquestions.org/questions/slackware-14/what-changes-must-be-made-in-a-slackbuild-from-11-x-to-build-for-slackware64-current-778904/)

Alexvader 12-30-2009 10:16 AM

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...

BRGDS

Alex

Alien Bob 12-30-2009 10:48 AM

In many cases, it will be enough to make sure that lib64 is used instead of lib, that "-fPIC" is added to the CFLAGS and CXXFLAGS, and that "-L/usr/lib64" is added to the LDFLAGS. See the FAQ at http://slackbuilds.org/faq/#x86_64 and a SlackBuild template file (http://slackbuilds.org/templates/template.SlackBuild) for some inspiration.

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

Eric

Alexvader 12-30-2009 10:52 AM

Thanks AlienBob

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 was packaged with src2pkg...

BRGDS

Alex

Alexvader 12-30-2009 11:07 AM

"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...?

BRGDS

Alex

Alien Bob 12-30-2009 01:21 PM

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.

Eric

Alexvader 12-30-2009 01:38 PM

Hi AlienBob,

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...


All times are GMT -5. The time now is 02:11 PM.