![]() |
SlackBuilds and Slackware64
Hi,
I've been following Slackware64-current on one of my machines for some time now and it has proven very stable. I have no need for 32-bit software, so I'll probably switch totally to Slackware64 when it is released. For some packages I compiled 64-bit versions using the scripts from Slackbuilds.org I noticed that many SlackBuild scripts already are prepared for Slackware64 with these lines: Code:
if [ "$ARCH" = "i486" ]; thenBut I wonder if this is enough to keep things clean... For instance, the libburn and libisofs SlackBuilds put the libraries in /usr/lib instead of /usr/lib64 So my question is: Should I alter the SlackBuild scripts (like in the "./configure" part) to use the /usr/lib64 folders, or leave it as it is? The software runs fine with the libraries in /usr/lib of course. Or should I just be patient and wait for an official Slackware64 release and a Slackware64-section on SlackBuilds.org? :) Any other hints / suggestions? |
Quote:
Code:
--libdir=/usr/lib${LIBDIRSUFFIX} \http://www.slackbuilds.org/template.SlackBuild |
I would advocate porting the script 'properly', which is to say:
Code:
LIBDIRSUFFIX=""Unlike 5 years ago when I started messing with this, pretty much everything will build very happily on 64 bit without too much coercion. If you want a second opinion on 64 build scripts, try http://builds.slamd64.com/ (also compatible with sbopkg I think). Between that an SBo, you've probably got your bases covered. One useful trick if things are not playing nice, is throwing in extra linker flags. Something I got very used to typing: LDFLAGS=-l/usr/lib64 CFLAGS=-fPIC -O2 ./configure --prefix=/usr --libdir=/usr/lib64 My guess is you won't ever have to do that, but if you start getting a lot of linker errors during compile, bear it in mind :) Best of luck, let us know how it turns out. - Piete. |
The SlackBuilds.org template was updated after slackware64-current was made public.
The LIBDIRSUFFIX parts will have to be added to any build that does not have it already, even with these changes many things will not build a proper x86_64 package. Code:
if [ "$ARCH" = "i486" ]; thenCode:
CFLAGS="$SLKCFLAGS" \cmake based stuff is a bit different of course, try something like: Code:
cmake \subject to change at any moment. |
uhm, my bad, I should have checked the updated template on SlackBuilds.org :o
OK, so I'll alter the SlackBuilds with this simple addition and do some testing later tonight. If it works fine (I guess it will), I'll contact the authors of the SlackBuild scripts that do not follow the newer template and suggest the changes. |
Quote:
|
For slamd64 I always compile using:
Code:
/configure --prefix=/usr --libdir=/usr/lib64As for cmake I use: Code:
cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIB_INSTALL_DIR=/usr/lib64 . |
Quote:
But will all SlackBuild scripts have to pass through a new evaluation to be listed as "13.0 compatible"? Or will there be a category for "64-bit compatible"? Some SlackBuild scripts need to be split because they use different "sources" for 32 & 64 bit (Opera comes to mind). Others simply won't be available for 64-bits, like GoogleEarth, since there is no 32-bits "source" available. Ah well, I'll just wait for the new release and see what will happen. |
Quote:
|
Quote:
"Anxiety leads to the dark side" :jawa: |
| All times are GMT -5. The time now is 01:47 AM. |