If you wanted to bypass the package manager, you could always install everything you compile under /usr/local. Then it will be separate and easily tracked. Ever wondered why /usr/local is empty after a fresh install?

That said, I always package the stuff I compile. It's just too easy under Slackware.

Should be:

make install DESTDIR=/work install

Its easier just to find someone who already made a package. Download that, rip out the slack.Build file and then modify it to your liking updating it for use with newer sources. Thats what I did with mplayer and gaim anyway. The source for both of those can be found on CD3 in the source directory.

KnightHawk,thanks for your reply.

Sorry I am quite a newbie in terms of compiling from source code. What I did before is just download the package file from linuxpackage.net. So,as you told me,I can modify the source file from the Disc3. But how to modify them?What do you mean?Would you mind clarify it a little bit?

I really appreciate your great help.

I prefer compiling from source, especially for program that needs lot of deps, and checkinstall in case something wrong, because sometimes package can't meet your need. But if i know a package doesn't need lot of deps and won't mess my box then I'll use package.
Sometimes I even use rpm -ivh --nodeps for suse rpm (trackballs, lincity, all rpm game), and it works fine.

How / Is making a *.tgz file with CheckInstall different from an 'official' *.tgz?

I guess I don't understand why someone would go through the trouble of finding a package, download it, rip the slackbuild script, download fresh source, modify the slackbuild to suit, and compile?

./configure && make && checkinstall -S

Done.

mdarby, checkinstall is cool, but the application needs a little more work & polish, i used it successfully on smaller source packages like lame and wget, but when i tryed to run it when i compiled gimp-2.2.9 checkinstall could not make a slackware package out of it, the compile and install worked just fine & without any errors on my first try too...

i think checkinstall is a good project but still a work in progress

I've had some odd issues with it on Debian now that you mention it. It created the *.deb just fine, but it wouldn't install it for some reason. I installed the packaged with no problem afterwards though.

It may or may not be different. Not enough information is provided to give an answer.

Some ways you can get differing results:

You do not have a full Slackware install on your local system. The package you create locally will not have any unmet dependencies (if it builds, since you can't compile against a library that isn't there). While this may be considered a plus to some (the software is "custom tailored" to your system), you may be missing some functionality, especially if you add other optional dependencies to your system and expect everything to Just Work.

Furthermore, SlackBuilds are better than checkinstall. As an example, try using checkinstall to package up FFMpeg. You will have no immediate indication that the packaging has not worked, but it will have failed. How? Well, there will be a package created, to be sure. Problem is, the package will have next to nothing in it. You'll need to examine package logs or the actual package itself to see this. You will have no indication that things are a mess, though, because FFMpeg will have been installed (even if you told checkinstall NOT to install it, as a matter of fact). Note that what I'm saying is that checkinstall will INSTALL FFMpeg (not PACKAGE) and it will create a bogus package, which gets "installed".

I use FFMpeg as an example, but there are many packages in the same boat, namely that they don't honor the "destdir=" directive. Taking the time to create your own SlackBuild script, you will realize this. Using checkinstall, you won't, unless you go looking. So why not check out what checkinstall did? Because one could spend that time skipping checkinstall all together and writing a SlackBuild script.

I used to think checkinstall was pretty cool. It has limitations, and you'll want to learn all the options so you can customize your packages. SlackBuilds are just bash scripts. I think that most people would be better served learning bash scripting (which is often useful) instead of learning to whip checkinstall into line when it acts up.

Hello all,

I have some questions about how we could use the CFLAGS/CXXFLAGS.
If we use "-march=i486 -mcpu=i686" flags, it means that it is i686 optimized and i386 compatible. Now, how can we optimize all compiled applications for one particular processor type (in my case a amd athlon xp)?
If I use/export these flags (taken from a gento_safe_cflags wiki) it is good?
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

Also, can we create something like "/etc/make.conf" in the aim to define theses flags only once for all the next compiled app?


PS: any correction about my English will be also very appreciated

I find the best approach is to create own custom SlackBuild scripts and keep them in a similiar hierarchy subtree like in original Slack repo. It is easy to tweak one template for the concrete package, generate and fill slack-desc file and optionaly create doinst.sh installation script. Once done, building of updated version is very simple. It is a good practice to build all packages as unprivileged i.e. non-root user with fakeroot tool.
To keep filesystem clean and be able to easily remove or upgrade installed software, installing through packages is the only way.

-march=i486 -mcpu=pentium3

In my case, would OPTIMIZE it as MUCH as possible for a pentium3 without breaking compatibility with a 486. The binary will run faster on a pentium3, but slower on a 486.(but it will still work on 486+)

I don't think there is a way to make a /etc/make.conf in slackware, but what you can do is add
To your ~/.bashrc and it will automatically apply those cflags when you open a terminal, so basically everytime you run make after adding that and restarting a terminal you will have your cflags applied automatically.

Your english is perfect. I couldn't even tell you were not a native speaker. THe only thing i see is you said, "a amd athlon xp" instead of "an amd athlon xp". Although that could just be a typo, and no one would even notice anyway(i didn't).

Plus you need to make sure to set the proper ownership/permissions on files that go into any */bin or */sbin directory. Then you need to gzip/bzip the man and info pages. Oh and don't forget to stip the binaries!

Such fun!



Later,
MMYoung

[EDIT]
BTW - here's how I do all that in my build scripts:

# Need to make sure that all the files in any "bin" directories have the proper ownership
chown root.bin ${BUILD}usr/bin/*
chown root.bin ${BUILD}usr/sbin/*
chown root.bin ${BUILD}bin/*
chown root.bin ${BUILD}sbin/*
chown root.bin ${BUILD}usr/X11R6/bin/*

# Now I need to strip any ELF binaries and gzip any manpages
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "current ar archive" | cut -f 1 -d : | xargs strip --strip-debug 2> /dev/null
bzip2 -9q ${BUILD}usr/man/*/*
bzip2 -9q ${BUILD}usr/info/*

Nothing special, or any great thinking, on my part. I just used the stuff suggested on Linuxpackages.net. That's the great thing about *most* of this kind of thing, it's already done for you all you have to do is find it, copy it over and then figure out what it all does for yourself. But while you are figuring it all out you can make packages like a pro!
[/EDIT]

CHOST="i486-slackware-linux" in slackware as reported with gcc -v

Is there a need to set CHOST anyway ? Does that optimize something ?

i prefer compiling, you can optimise everything for your processor, and you can add any paramaters you made need.