[opensuse] question about compiling an app and installing
Hello All, I have been using Linux for a long time now but up until recently I never really did a lot of "configure make install" type builds for any of my boxes. As luck had it, there was an rpm available 99% of the time. Recently, I have run into a lot of scenarios where I needed a newer version of something and I had to go through a manual build process. Currently, have 3 systems that are pretty much identical. So lets say I want a newer version of wireshark or a gnome-applet that suse does not have yet in a repo. I would do the standard config make install procedure on all three boxes. I did notice that if the linux systems seem to be the same (ie. x86, i386) I can copy compiled binaries over to another box and I can use them there. Here is where my questions begin :) #1. Most of these apps have a lot of requirements when you build them, for example libpcap-devel or gnome-something-devel. I realized I do not need the "*devel*" rpms to be installed on the boxes i was compiling to. However, since there is no dependancy checking when I copy something over how can I know that the libpcap libraries actually exist? I assume my app will bomb out in the middle? #2. If I compile something on 586 openSuse will it work in 586 CentOS ? Is this just not a smart thing to do? Should you only copy between the same distro? #3. is there any way to keep track of the files installed? Or am I doing something findamentally wrong? Do I ./configure and make on one system and then do a make install on all of them? #4. How does one easily uninstall stuff that is installed by these methods? Thanks for any help -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2007-02-04 at 11:09 -0500, Rami Michael wrote:
#1. Most of these apps have a lot of requirements when you build them, for example libpcap-devel or gnome-something-devel. I realized I do not need the "*devel*" rpms to be installed on the boxes i was compiling to. However, since there is no dependancy checking when I copy something over how can I know that the libpcap libraries actually exist? I assume my app will bomb out in the middle?
Or bomb out right at the start, which is when shared libraries are usually loaded. For many applications you can use a --disable-shared flag in a configure file so that the library becomes part of the binary you build. This will increase file size, sometimes dramatically, but will often make the application start faster and will make it much more likely to work when copied to another system. If you know there are particular shared libraries, you can build local (i.e. in /usr/local/lib) versions and copy them too.
#2. If I compile something on 586 openSuse will it work in 586 CentOS ? Is this just not a smart thing to do? Should you only copy between the same distro?
You should be fine unless you pass specific flags to the compiler. Typically I use something like $ export -march=pentium4 -O2 -mfpmath=sse -msse -msse2 -malign-double -Wall -pipe -Wno-long-long $ ./configure Without the first line, I get a generic binary that should run on different distros (as long as they are based on basic i386 IIRC). With the flags, it will only run on systems with newer P4 chips, though should still be distribution-independent. As an example, I've compiled gcc itself on one system and then copied the binaries to another. It works.
#3. is there any way to keep track of the files installed? Or am I doing something findamentally wrong? Do I ./configure and make on one system and then do a make install on all of them?
Make sure they are all installed in /usr/local rather than anywhere else. Then you can typically copy the files in /usr/local/bin from one system to another without problems. SuSE doesn't install files to /usr/local/ and you're unlikely to overwrite anything (such as fonts in /usr/local/share/fonts) that you might otherwise have installed locally. There are alternatives, such as building in a subdirectory of /opt, but /usr/local is searched for binaries; so no special configuration is required.
#4. How does one easily uninstall stuff that is installed by these methods?
If you haven't too many files, it's usually easy to identify and deleted the required ones from /usr/local/ make uninstall usually (but not always) removes all the files associated with a particular application). You could also try setting up rsync to mirror the whole /usr/local tree from one machine to another. Then when you delete files on the build machine (e.g. with a make uninstall) rsync (with --delete flag IIRC) from another machine will automatically delete the required files for you. -- JDL -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* John D Lamb
make uninstall usually (but not always) removes all the files associated with a particular application).
but may also delete files common to other packages and may cause rpm apts to fail and worse. Better to use and rpm designed for your distro or, if not available, use checkinstall. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 OpenSUSE Linux http://en.opensuse.org/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 04 Feb 2007 21:24:22 +0000, John D Lamb wrote:
On Sun, 2007-02-04 at 11:09 -0500, Rami Michael wrote:
Or bomb out right at the start, which is when shared libraries are usually loaded.
It just won't start. The dynamic linker reads special fields in the ELF headers of a binary and tries to load the libraries recorded there. If any of these is missing, the application won't be started.
For many applications you can use a --disable-shared flag in a configure file so that the library becomes part of the binary you build.
Many libraries nowadays only come in dynamic versions and static libraries are getting scarcer.
This will increase file size, sometimes dramatically, but will often make the application start faster and will make it much more likely to work when copied to another system.
And will make maintenance a nightmare! If, for instance, a security bug is discovered in a library, *every* app that linked in the library statically has to be rebuilt. Contrast this with simply replacing one dynamic library.
As an example, I've compiled gcc itself on one system and then copied the binaries to another. It works.
Yes, but it usually doesn't buy you much. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 07 February 2007 02:00, Philipp Thomas wrote:
On Sun, 04 Feb 2007 21:24:22 +0000, John D Lamb wrote:
On Sun, 2007-02-04 at 11:09 -0500, Rami Michael wrote: ...
This will increase file size, sometimes dramatically, but will often make the application start faster and will make it much more likely to work when copied to another system.
And will make maintenance a nightmare! If, for instance, a security bug is discovered in a library, *every* app that linked in the library statically has to be rebuilt. Contrast this with simply replacing one dynamic library.
It also thwarts the kernel's ability to share the in-memory image of disk blocks among all concurrent users of a given shared object file. This increases the demand for physical RAM and, in some circumstances, the amount of paging or swapping traffic the system generates.
...
Philipp
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 7 Feb 2007 07:57:23 -0800, Randall R Schulz wrote:
It also thwarts the kernel's ability to share the in-memory image of disk blocks among all concurrent users of a given shared object file.
Yeah, I forgot about that one. And add to it that you can't link in glibc statically if your code uses any of the name resolution functions like gethostbyname(3), because this needs the nss*.so libraries that are *always* loaded dynamically even when glibc is otherwise statically linked in (the linker in Solaris errors out if it encounters such a situation) . Now guess what happens if the statically linked libc dynloads nss modules that belong to glibc of a different version where the ABI changed Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 04 February 2007 10:09, Rami Michael wrote:
Hello All,
I have been using Linux for a long time now but up until recently I never really did a lot of "configure make install" type builds for any of my boxes. As luck had it, there was an rpm available 99% of the time.
Recently, I have run into a lot of scenarios where I needed a newer version of something and I had to go through a manual build process. Currently, have 3 systems that are pretty much identical. So lets say I want a newer version of wireshark or a gnome-applet that suse does not have yet in a repo.
I would do the standard config make install procedure on all three boxes. I did notice that if the linux systems seem to be the same (ie. x86, i386) I can copy compiled binaries over to another box and I can use them there.
Here is where my questions begin :)
#1. Most of these apps have a lot of requirements when you build them, for example libpcap-devel or gnome-something-devel. I realized I do not need the "*devel*" rpms to be installed on the boxes i was compiling to. However, since there is no dependancy checking when I copy something over how can I know that the libpcap libraries actually exist?
Use the checkinstall program that will help you to build package for certain distribution. Later when you install package the package management software will take care of dependencies, than when you don't want them it is easy to get rid of them.
I assume my app will bomb out in the middle?
It can happen to break, but there is no siple rule. It depends what is installed, what versions of libraries, where is location of applications libraries and configuration files in the file system of specific distro.
#2. If I compile something on 586 openSuse will it work in 586 CentOS?
May or may not. See above.
Is this just not a smart thing to do?
It is not smart. It can be used as desperate move if you are out of time and not working application is the smallest of bad things that can happen to you.
Should you only copy between the same distro?
Same distro has release versions, updates, and it can happen that application doesn't work anyway, for the very same reasons that it will fail on another distro. If you know what to tweak, it can work, but simply compiling on one machine and then copy may produce strange results. If application refuses to run it is a simple bug that is announcing its presence very loud. It may work, but it may have some subtile bug that will produce bad results. Better compile on the system that program will run on.
#3. is there any way to keep track of the files installed?
See answer on #4. It is the same group of problems.
Or am I doing something findamentally wrong? Do I ./configure and make on one system and then do a make install on all of them?
The ./configure will check is it possible to compile application on particular system, so to avoid manual check or bad surprises, consider configure as machine architecture and software installation specific. So the basic answer is no, but see above #2.
#4. How does one easily uninstall stuff that is installed by these methods?
People spent substantial amount of time to create packaging systems and supporting applications with one goal in mind, to save time later and make applications management easier task. Why not to use them? If you are in need for brand new software check software repositories, like those listed on: http://en.opensuse.org/Additional_YaST_Package_Repositories Many people like you like/need to have the latest, and other that are skilled in package creation decided that is the best way to help others. They are making repositories where you can find newer versions of packages that are included in distro, and more programs that are not included for various reasons. -- Regards, Rajko. http://en.opensuse.org/Portal -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-02-04 at 11:09 -0500, Rami Michael wrote:
I have been using Linux for a long time now but up until recently I never really did a lot of "configure make install" type builds for any of my boxes. As luck had it, there was an rpm available 99% of the time.
...
I would do the standard config make install procedure on all three boxes. I did notice that if the linux systems seem to be the same
Substitute 'make install" with "checkinstall" (see man). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFzSPHtTMYHG2NR9URAhlQAJ9rfRUpgpTCpY2EjyjwibzIf/6AxQCfWzw0 qAVKwQqzl+yfHXO8Kn4sLcI= =wexl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi All,
Sorry for the late reply, I didn't even think my post went through to
the list, I waited 30 minutes and didn't see it come up, so I thought
it was not allowed for some reason. Anyways, thanks very much for the
feedback, it was all very helpfull. I am going to try this out on
Monday.
I agree with the dynamic vs static libraries stuff you guys talked
about, it makes good sense.
This is another generic question but in my dealings with linux I have
found this to be the case. Anything installed by the OS itself (the
distro I mean) is in /usr , anything added seperately by the user
should go in /usr/local or /opt. That being the case...
Lets say you have two apps on your system that need different versions
if the same program, lets use openssl as an example. One only works
with 0.9.6 (lets say this is installed by the distro) and one needs
0.9.7 or higher. Is it okay to compile and install the 0.9.7 on the
system as long as it is in /usr/local ? there will be no issues as
long as they ae in seperate directories and you tell the apps in need
where to look for them?
I assume apps automatically look in /usr first and then /usr/local
I will do my research and get back to you guys so that others my
benefit from my work as well!
Regards
On 2/9/07, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2007-02-04 at 11:09 -0500, Rami Michael wrote:
I have been using Linux for a long time now but up until recently I never really did a lot of "configure make install" type builds for any of my boxes. As luck had it, there was an rpm available 99% of the time.
...
I would do the standard config make install procedure on all three boxes. I did notice that if the linux systems seem to be the same
Substitute 'make install" with "checkinstall" (see man).
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76
iD8DBQFFzSPHtTMYHG2NR9URAhlQAJ9rfRUpgpTCpY2EjyjwibzIf/6AxQCfWzw0 qAVKwQqzl+yfHXO8Kn4sLcI= =wexl -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Carlos E. R. -
John D Lamb -
Patrick Shanahan -
Philipp Thomas -
Rajko M. -
Rami Michael -
Randall R Schulz