LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 12-04-2005, 05:40 AM   #16
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,807

Rep: Reputation: 234Reputation: 234Reputation: 234

Quote:
Originally Posted by Xian
I was just under the impression that the other posters I quoted were strictly installing from source, with no additional utilities that aided with managing the system packages. And if this were the case then I'd be interested in what method they do use for this function.
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.
 
Old 12-04-2005, 06:32 AM   #17
AxeZ
Member
 
Registered: Sep 2002
Location: Novi Sad, Vojvodina
Distribution: Slackware, FreeBSD
Posts: 386

Rep: Reputation: 32
Quote:
Originally Posted by liquidtenmilion
7 make DESTDIR=/work install

Should be:

make install DESTDIR=/work install
 
Old 12-06-2005, 06:15 PM   #18
KnightHawk
Member
 
Registered: Sep 2005
Posts: 128

Rep: Reputation: 15
Quote:
Originally Posted by Swift&Smart
liquidtenmilion and all folks have given invaluable suggestions to me, thanks a lot.

liquidtenmilion,I personally prefer your option to make a slackware package because it's clear and intact if I want to remove/upgrade the package.However, can you point me to any website which you learned from regarding this package creation?

That's the new icon.

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.
 
Old 12-06-2005, 09:18 PM   #19
Swift&Smart
Member
 
Registered: Jan 2003
Location: Hong Kong,China
Distribution: Slackware,OpenSUSE
Posts: 472

Original Poster
Rep: Reputation: 30
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.
 
Old 12-06-2005, 10:11 PM   #20
karunamurti
LQ Newbie
 
Registered: Sep 2005
Distribution: Slackware
Posts: 25

Rep: Reputation: 15
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.
 
Old 12-06-2005, 10:38 PM   #21
mdarby
Member
 
Registered: Nov 2004
Location: Columbus, Ohio
Distribution: Slackware-Current / Debian
Posts: 795

Rep: Reputation: 30
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.
 
Old 12-07-2005, 05:52 AM   #22
Okie
Member
 
Registered: Mar 2002
Location: Oklahoma
Posts: 964

Rep: Reputation: 34
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
 
Old 12-07-2005, 01:38 PM   #23
mdarby
Member
 
Registered: Nov 2004
Location: Columbus, Ohio
Distribution: Slackware-Current / Debian
Posts: 795

Rep: Reputation: 30
Quote:
Originally Posted by Okie
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.
 
Old 12-07-2005, 10:16 PM   #24
shilo
Senior Member
 
Registered: Nov 2002
Location: Stockton, CA
Distribution: Slackware 11 - kernel 2.6.19.1 - Dropline Gnome 2.16.2
Posts: 1,132

Rep: Reputation: 49
Quote:
Originally Posted by mdarby
How / Is making a *.tgz file with CheckInstall different from an 'official' *.tgz?
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.

Last edited by shilo; 12-07-2005 at 10:18 PM.
 
Old 12-09-2005, 07:33 AM   #25
budo-ka
LQ Newbie
 
Registered: Sep 2005
Location: Belgium
Distribution: slackware 10.2
Posts: 3

Rep: Reputation: 0
Quote:
Originally Posted by liquidtenmilion
I usually always use source, and then make a package for it. I currently have 100+mb of packages in ~/packages.

To do this all that is usually needed is.

1. Read documentation in tarball.
2. ./configure --help to find out all the additional options.
3. export CFLAGS="-O2 -march=i486 -mcpu=i686 -pipe";export CXXFLAGS="-O2 -march=i486 -mcpu=i686 -pipe" (editing them to whatever i need for that particular package.
4. ./configure --prefix=/usr --whatever-other-options
5. make
6 su
7 make DESTDIR=/work install
8. cd /work and then strip binaries, move/remove unnecessary/misplaced files, mkdir install, then add a slack-desc.
9. cd back into /work and do "makepkg programname-version-i686-1asw.tgz

Then i have a nice package that i can later remove/upgrade if needed. I can then do an rm -rf /work and i can remove the source code.

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
 
Old 12-09-2005, 08:46 AM   #26
dunric
Member
 
Registered: Jul 2004
Distribution: Slackware, FreeBSD
Posts: 483

Rep: Reputation: 92
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.
 
Old 12-09-2005, 04:44 PM   #27
liquidtenmilion
Member
 
Registered: May 2004
Location: South Carolina
Distribution: Slackware 11.0
Posts: 606

Rep: Reputation: 31
Quote:
Originally Posted by budo-ka
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?

-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
Code:
export CFLAGS="-O2 -march=i486 -mcpu=athlon-xp -pipe"
export CXXFLAGS="-O2 -march=i486 -mcpu=athlon-xp -pipe"
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.

Quote:
PS: any correction about my English will be also very appreciated
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).
 
Old 12-09-2005, 07:42 PM   #28
MMYoung
Member
 
Registered: Apr 2004
Location: Arkansas
Distribution: Ubuntu 8.10
Posts: 365

Rep: Reputation: 30
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]

Last edited by MMYoung; 12-09-2005 at 07:52 PM.
 
Old 12-09-2005, 08:39 PM   #29
keefaz
Senior Member
 
Registered: Mar 2004
Distribution: Slackware
Posts: 4,617

Rep: Reputation: 136Reputation: 136
CHOST="i486-slackware-linux" in slackware as reported with gcc -v

Is there a need to set CHOST anyway ? Does that optimize something ?
 
Old 12-09-2005, 08:50 PM   #30
sega01
LQ Newbie
 
Registered: Oct 2005
Location: NC
Distribution: slackware current
Posts: 4

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


Reply

Tags
compile, package


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for a multiple file search and replace tool, prefer graphical haimeltjnfg Linux - Software 6 02-02-2005 11:53 PM
tgz file doesn't end in .tgz? detpenguin Slackware 4 05-15-2004 08:13 PM
Do you prefer Curses based or Graphical File Mangers? njbrain General 19 04-25-2004 11:27 PM
tgz vs. rpm vs. source? Joey.Dale Linux - Distributions 3 01-08-2004 10:02 PM
tgz files and source nny0000 Slackware 2 11-18-2003 05:18 AM


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

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration