LinuxQuestions.org
Visit the LQ Articles and Editorials section
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
 
LinkBack Search this Thread
Old 11-19-2007, 07:17 AM   #1
Unregistered
Member
 
Registered: Apr 2007
Posts: 63

Rep: Reputation: 15
what actually happens under the hood when I type ./configure, make and make install?


I know it would check environment variables and stuff like enable/disable options but does it write to a configuration file in the folder afterwards? and if so, if I run ./configure again, would the configuration file be overwritten?

as for make I know it would compile if the configuration is done without errors but what if there was an error in the configuration process? Usually it gives me some kind of error message like target not found, but would the compilation process be carried out halfway or would it not be carried out at all?

all that make install does is copy the appropriate files into the appropriate directory?
 
Old 11-19-2007, 08:46 AM   #2
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,904

Rep: Reputation: Disabled
Quote:
Originally Posted by Unregistered View Post
I know it would check environment variables and stuff like enable/disable options but does it write to a configuration file in the folder afterwards? and if so, if I run ./configure again, would the configuration file be overwritten?
config.log would typically be the configure log, and yes, it should be overwritten on subsequent runs of configure.

Quote:
as for make I know it would compile if the configuration is done without errors but what if there was an error in the configuration process? Usually it gives me some kind of error message like target not found, but would the compilation process be carried out halfway or would it not be carried out at all?
There will often be some object files (*.o) and such already created, so if you get this far before noticing a problem, it's a good idea to do "make clean" before continuing.

Quote:
all that make install does is copy the appropriate files into the appropriate directory?
Not necessarily, but ideally, yes. You can look at the actual "install" target in the Makefile to see exactly what it does; this will often require you to "work backwards" through some other targets perhaps, but that's not too difficult

One particular example of an app whose Makefile doesn't just "copy ... files into the appropriate director[ies]" is apcupsd. It attempts to patch the /etc/rc.d/rc.6 script and also installs /etc/rc.d/rc.apcupsd outside the package directory (DESTDIR); it's apps like this that make it a good idea to always test the whole process as a normal user before doing anything as root.
 
Old 11-19-2007, 11:59 AM   #3
duryodhan
Senior Member
 
Registered: Oct 2006
Distribution: Slackware 12 Kernel 2.6.24 - probably upgraded by now
Posts: 1,054

Rep: Reputation: 46
Quote:
It attempts to patch the /etc/rc.d/rc.6 script and also installs /etc/rc.d/rc.apcupsd outside the package directory (DESTDIR); it's apps like this that make it a good idea to always test the whole process as a normal user before doing anything as root.
how would I do that ? with a prefix to /tmp and then checkng the output ?
 
Old 11-19-2007, 12:06 PM   #4
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,904

Rep: Reputation: Disabled
Quote:
Originally Posted by duryodhan View Post
how would I do that ? with a prefix to /tmp and then checkng the output ?
Something like this:

Code:
./configure 
make
mkdir -p /tmp/testing-appname
make install DESTDIR=/tmp/testing-appname
Then inspect the contents of /tmp/testing-appname. This is a great way to find out whether manpages need to be compressed (they usually do), whether --mandir needed to be explicitly defined, what config files to rename to *.new and handle in doinst.sh, whether to update the shared mime info, desktop database, etcetera, and so on...

Of course, if you encounter an error in the "make install" above, then you know that something's trying to write to a location it's not allowed to write, or some other operation is trying to happen that you can't do as a normal user. Sometimes this is minor - for example, the install target might try to explicitly set ownership of the installed files with something like this:
Code:
install -o root -g wheel -m 0750 somefile $(DESTDIR)/$(BINDIR)
If this is the only thing causing a problem, then you'll be fine to go ahead and do the build as root. However, you might have to patch that out of the Makefile temporarily to verify that nothing else undesirable is going on.
 
Old 11-19-2007, 12:36 PM   #5
Lufbery
Senior Member
 
Registered: Aug 2006
Location: Harrisburg, PA
Distribution: Slackware 64 14.0
Posts: 1,139
Blog Entries: 29

Rep: Reputation: 119Reputation: 119
Hey Robby,

I'm hijacking the thread slightly, but I think this is still on-topic:

How would I go about really learning what's desirable or not? There's got to be some guidelines on which permissions are appropriate in which circumstances, but I'll be darned if I can figure them out on my own.

For instance, there seems to be a lot of heartburn among people making packages when a packages uses setuid to give root permissions to regular users for some tasks. But sometimes that's a good thing, right? So how does one learn to tell good practice from bad?

Regards,

-Drew
 
Old 11-19-2007, 01:52 PM   #6
weibullguy
ReliaFree Maintainer
 
Registered: Aug 2004
Location: Kalamazoo, Michigan
Distribution: Slackware-current, Cross Linux from Scratch, Gentoo
Posts: 2,676
Blog Entries: 1

Rep: Reputation: 204Reputation: 204Reputation: 204
Quote:
Originally Posted by Unregistered View Post
I know it would check environment variables and stuff like enable/disable options but does it write to a configuration file in the folder afterwards? and if so, if I run ./configure again, would the configuration file be overwritten?
The configure script generates a log of everything that it checks and the results of these checks. That log file is helpful if the configuration fails, but not so much otherwise. The really important files that configure creates are the Makefiles. The Makefiles have the build recipes specific for your machine.

Quote:
Originally Posted by Unregistered View Post
as for make I know it would compile if the configuration is done without errors but what if there was an error in the configuration process? Usually it gives me some kind of error message like target not found, but would the compilation process be carried out halfway or would it not be carried out at all?
If the configuration fails, there will be no Makefiles generated and, thus, no target when you issue the make command. However, successful configuration doesn't guarantee a successful compilation and link. For example, configure might check that you have libfoo, but not the version. You may have a version of libfoo that is too old or too new and the compilation/linking will then fail.

Quote:
Originally Posted by Unregistered View Post
all that make install does is copy the appropriate files into the appropriate directory?
It does a little more than that. It will create directories if needed, it will update the dynamic library database, it will set permissions on files/directories, etc. But, essentially it just copies files although it should use install rather than cp.
 
Old 11-19-2007, 02:24 PM   #7
MannyNix
Member
 
Registered: Dec 2005
Location: ~
Distribution: Slackware -current, OpenBSD
Posts: 449

Rep: Reputation: 41
I really like to see how slackers are familiar with ./configure make && make install because of 'rolling their own' and slackbuilds.
Sometimes people forget that when you type: apt-get foo, emerge foo, pacman -S foo, rpm -i foo, make install clean foo, pkg_add -r foo, installpkg foo, etc, etc. Somebody has done the ./configure make, etc. read the REAME and INSTALL for you.
The other thing i like is the 'purity' you are allowed to retain in your build scripts instead of relying on functions and package manager customizations.
Interesting thread. I'll keep and eye on it.
 
Old 11-19-2007, 03:36 PM   #8
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,904

Rep: Reputation: Disabled
Quote:
Originally Posted by Lufbery View Post
How would I go about really learning what's desirable or not? There's got to be some guidelines on which permissions are appropriate in which circumstances, but I'll be darned if I can figure them out on my own.

For instance, there seems to be a lot of heartburn among people making packages when a packages uses setuid to give root permissions to regular users for some tasks. But sometimes that's a good thing, right? So how does one learn to tell good practice from bad?
Well, I wish there were an easy answer to that.

Let's look at slackins as an example application: http://slackbuilds.org/repository/12.0/system/slackins/

This is essentially a gui frontend to pkgtool(8) and friends, so it simply MUST have root privileges in order to be useful.

Therefore, you can install it with with uid=root, gid=root, mode=0755 ("normal" ownership and permissions for binaries), and then you'll have to be root when you execute in order to do anything with it. Doing it this way will mean that lots of people will resort to doing something insecure with X in order to run a gui app as root inside the context of a user session.

Alternatively, you can choose to install it suid with uid=root, gid=wheel, mode=4750 (yes, that's redundant - 4xxx means suid). This will elicit screaming from some about "OMG!!!111 INSECURE - SUID!!!111" *but* they should generally shut up. We've already considered the alternative, so let's look at the practical implications of this. Yes, it is suid, but only members of the 'wheel' group can even execute it. Even *if* someone undesirable is in the 'wheel' group, they *still* have to enter the root password in order to do anything with slackins.

Long story short, installing this one suid and only executable by members of a specified group (in this case, 'wheel' was the obvious choice) is actually *more* secure than the alternative.

Ultimately, I guess that doesn't answer your question, but that's because I'm not sure *how* to answer it. It's basically a matter of "look at the big picture" and decide what the *best* option is within the context of the application's purpose, usage patterns, etcetera...
 
Old 11-19-2007, 04:14 PM   #9
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
Quote:
Originally Posted by rworkman View Post
Therefore, you can install it with with uid=root, gid=root, mode=0755 ("normal" ownership and permissions for binaries), and then you'll have to be root when you execute in order to do anything with it. Doing it this way will mean that lots of people will resort to doing something insecure with X in order to run a gui app as root inside the context of a user session.
Maybe I misunderstood something but why this is wrong:

Code:
su -
xhost +root
export DISPLAY=:0
your-program
or just:

Code:
su
your-program

Last edited by Alien_Hominid; 11-19-2007 at 04:16 PM.
 
Old 11-19-2007, 04:18 PM   #10
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,904

Rep: Reputation: Disabled
I'm not saying there's anything necessarily *wrong* or *bad* with doing either - I'm simply saying that lots of people won't do it correctly. That being said, yes, I know I'm not exactly a poster boy for "let's protect people from their own stupidity," but I have my moments... :-)

As an aside, either of those means more work...

Last edited by rworkman; 11-19-2007 at 04:19 PM.
 
Old 11-19-2007, 04:31 PM   #11
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
Btw, why doesn't xhost +root work? According to manual it should, but I am getting an error smth similar to root is not a hostname.


P.S. Third or fourth time when I'm getting angry at Linux (hdparm, wall thing and ctrl+d were very irritating). I can't understand why it is so hard to write proper documentation (even worms has a manual). The funniest thing is when I get a suggestion in man smth to read complete manual running info smth, but there is no info smth or it is the same as man smth. Any help for such issues is very appreciated.

Last edited by Alien_Hominid; 11-19-2007 at 04:33 PM.
 
Old 11-19-2007, 04:40 PM   #12
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,904

Rep: Reputation: Disabled
Hmmm... Good question.

Code:
liberty $ xhost +root@localhost
root@localhost being added to access control list
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  109 (X_ChangeHosts)
  Value in failed request:  0xfe
  Serial number of failed request:  7
  Current serial number in output stream:  9
 
Old 11-19-2007, 04:50 PM   #13
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,111

Rep: Reputation: Disabled
Quote:
Originally Posted by Alien_Hominid View Post
Btw, why doesn't xhost +root work? According to manual it should, but I am getting an error smth similar to root is not a hostname.
It would be better to use xauth instead of xhost if you want to enable root access to your X display. See my Wiki example:
http://alien.slackbook.org/dokuwiki/...=sudo#x_and_su
Code:
echo $DISPLAY                  # you'll be needing this value 3 lines below
sudo -i                        # or "su -" on older Slackwares
xauth merge ~alien/.Xauthority # use your own username here instead of "alien"
export DISPLAY=:0.0            # use the value of DISPLAY you've seen 3 lines before
Alternatively, Slackware supports
Code:
sudo -s
which will let you run X applications as root without further configuration; the downside is that you won't get /sbin:/usr/sbin:/usr/local/sbin into your PATH.

Eric
 
  


Reply


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
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
these commands are not working on my server (./configure, make, make install) Anil Kumar K Linux - Software 3 07-02-2007 07:23 AM
basic configure-make-make install question bigwheel Slackware 4 01-14-2007 10:09 AM
configure, make and make install commands don't work for me Fenster Fedora 8 08-18-2004 10:58 AM
Installed using ./configure, make, make install, how to remove? EnVoy Mandriva 4 03-10-2004 07:05 PM
Can I automate the tar, ./configure, make, and make install of about 50 packages? JoeLinux Linux - General 2 04-13-2002 03:35 AM


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

Main Menu
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