LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   what actually happens under the hood when I type ./configure, make and make install? (http://www.linuxquestions.org/questions/slackware-14/what-actually-happens-under-the-hood-when-i-type-configure-make-and-make-install-600814/)

Unregistered 11-19-2007 07:17 AM

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?

rworkman 11-19-2007 08:46 AM

Quote:

Originally Posted by Unregistered (Post 2964018)
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.

duryodhan 11-19-2007 11:59 AM

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 ?

rworkman 11-19-2007 12:06 PM

Quote:

Originally Posted by duryodhan (Post 2964316)
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.

Lufbery 11-19-2007 12:36 PM

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

weibullguy 11-19-2007 01:52 PM

Quote:

Originally Posted by Unregistered (Post 2964018)
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 (Post 2964018)
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 (Post 2964018)
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.

MannyNix 11-19-2007 02:24 PM

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.

rworkman 11-19-2007 03:36 PM

Quote:

Originally Posted by Lufbery (Post 2964361)
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...

Alien_Hominid 11-19-2007 04:14 PM

Quote:

Originally Posted by rworkman (Post 2964549)
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


rworkman 11-19-2007 04:18 PM

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...

Alien_Hominid 11-19-2007 04:31 PM

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.

rworkman 11-19-2007 04:40 PM

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


Alien Bob 11-19-2007 04:50 PM

Quote:

Originally Posted by Alien_Hominid (Post 2964605)
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


All times are GMT -5. The time now is 06:53 PM.