Rebuilding a Slackware Package With Slackbuild Scripts
 

Now that I finally have a broadband connection, and finally have access to source code, I am trying to venture into the world of building Slackware packages. My first effort is the FreeType 2.1.9 package. I want to rebuild the package with the ByteCode Interpreter enabled because this one small mod provides a dramatic change in my desktop appearance.

I am using the 11.0 source files provided at the Slackware mirrors. I am using the stock SlackBuild script as my foundation. With appropriate modifications to the script I am using my own build working directory rather than the /tmp directory (which I have mounted noexec). The build script runs with no noticeable errors.

However, every time I create a new FreeType package, the compilation defaults to /usr/local rather than /usr. I do not understand why. The stock SlackBuild script contains the following, which I have not modified:

CFLAGS="$SLKCFLAGS" make setup CFG="--prefix=/usr $ARCH-slackware-linux"
make -j4 || exit 1
make install DESTDIR=$PKG

If I correctly understand the first line above, everything should compile to /usr, not /usr/local, but this is not the case. I realize from researching the problem that /usr/local is almost always the default option embedded into these make config scripts, but I thought the above is supposed to override that default setting. I do not know how to correct this problem.

Although the package is incorrectly compiled to use /usr/local, I think the build script is otherwise working as expected. I do get a tgz package built, permissions seem correct, etc. The resulting package is about twice the size of the stock package, but at this point I'm willing to assume the problem is caused by the incorrect /usr/local directory path. But one problem at a time for the moment. :)

This is new territory for me and all help is appreciated.

Thanks again!

You know that package is 2 1/4 years old... Still not sure why Slack doesn't use a more recent version... I haven't compiled that version myself so I can't help you. Don't know if you'll have any X problems by upgrading to a more recent version but it would be worth a try IMO. Atleast all the newer versions take a standard ./configure --prefix=/usr and actually do as advertised..

Looks to me like there should be a CFG variable in the Makefile that you are over riding at the command line. Why it's not working, not sure.. Usually what I do with old non-configure packages like this is just sed in the new options from the script instead of over riding at the prompt. That way, it just works because it's reading straight from the Makefile, like it seems to be doing anyway for you... :-)

My pick-up truck is 18 years old. My primary computer is 10 years old. My seldom-used TV is 27 years old. I have some hand-tools that are more than 30 years old. ;)

PV sees something in the 2.1.10 version that he does not like. Although I am always free to modify Slackware to my heart's content, I tend to trust him with these kinds of decisions because I do not have the time nor the desire to become a package expert. Besides, since he used and compiled 2.1.9 in 11.0, his build script should work, but does not.

Yes, that is what is happening. I can identify the config file that gets recreated on the fly with the build script that embeds the /usr/local variable, but other than performing all the steps manually, which would include editing that config file before performing a make install, I don't understand why the build script fails. If this build script is the actual one used by PV then why does the script fail? I want to learn how to use the build scripts and this one is not working.

You can get a SlackBuild and patch for the bytecode-enabled version of freetype2 here: http://www.slackware.com/~alien/slac...eetype2/build/ . It will probably need some tweaking for Slackware 11.0 and I hope I will get to that sometime soon. If not, look at where in the script I apply that patch, and then use it on Pat's Slackware 11.0 version of freetype2.SlackBuild.

Eric

I seem to recall looking at Pat's slackbuild script for freetype in 11.0/current and noticing that he includes a commented-out call to a diff file that enables the bytecode. The diff is included in the source directory so I think (although have not tried this) that one can just uncomment that line in the slackbuild and then rebuild the package. Would that work?

Yes that will work. Did not realize Pat did the preparation already.

Eric

Eric, et. al.,

Thanks again. I knew about your script and yesterday had already grabbed a copy to compare to the 11.0 script. One difference that you probably are aware is that the lines concerning X no longer apply because FreeType was split from the X package. Otherwise, your script and the newer 11.0 script are very similar. You add some more tweaks at the end, such as MD5 support, but I think the scripts are more or less the same.

Yes, PV has graciously maintained the line that enables the ByteCode Interpreter, but as mentioned, is commented out by default.

A note to any future reader of this thread. Initially I could not get anything to work. I kept receiving bad interpreter/permission denied messages. I knew this was related to file permissions, but I was running the script as root. Quite confusing for a while until I ran across another discussion where a fellow had a similar problem. The solution for him was the same for me. I mount /tmp in fstab as noexec and the build scripts default to /tmp. I then edited the script to use my special build area and then the script was happy.

But my original problem was not enabling the diff file, but the script installing everything in /usr/local rather than /usr as the --prefix=/usr option calls for.

Question: Perhaps the answer is obvious to seasoned software people, which I am not, but do I need to first update to 11.0 before trying to run the 11.0 script? I ask because I read something about versions of make, etc., and I wonder if my problem of the --prefix=/usr not working in the script is related to the version of make I am using, which is from the 10.2 distro version. I don't know how make is related to gcc, etc., but I know that gcc is newer in 11.0 than 10.2. Perhaps somebody can provide a snippet explanation about how these scripts might be dependent upon various other software? :confused:

I just ftp'ed the freetype directory and ran it. Works just fine for me. Obviously something with your box. Maybe because it's 10 years old.. ;)

Hi,

I'm trying to do the same and from what i've read in this thread, i just need to uncomment:
#zcat $CWD/freetype.bytecode.interpreter.diff.gz | patch -p1 --verbose || exit 1
and then run the freetype.slackbuild again, and everything should be fine.

But, don't i need to uninstall the pre installed package, or does the script take care of this ???

regards

The script freetype.SlackBuild will create a freetype package for you from the source code. You will have to install that package yourself, using the "upgradepkg --reinstall" command - the package is created in the /tmp directory.

If you edit the freetype.SlackBuild script so that the "1" in BUILD=${BUILD:-1} changes to something else, like "1.rosepower" then the created package will have another filename than the original (which is all for the better IMO) and then you can use the command Eric

Problem Solved
 

For future visitors to this thread, I solved the problem with the build script. On my testing partitions I updated Slackware to version 11.0 and the build script then worked flawlessly. Apparently there is a difference in the make utilities between version 10.2 and 11.0 that causes the /usr/local problem. I'm not sufficiently versed or knowledgeable to know what that difference might be and do not really care---as long as the build script works.

As I previously mentioned, the build script will fail if the /tmp directory is mounted noexec in fstab. Users then will have to mount /tmp without that option or modify the build script to operate in a different location. Because I use a special directory for my modest kernel builds, I chose the latter option. And this is more palatable to me anyway because now I can maintain this particular software.

More likely, the problem usually is between my ears. ;) But ignorance is curable with additional knowledge. The trick is finding and applying that knowledge.

im curious what does "bytecode interpreer" do exactly?