Advertisement

linux commands

Started by March 23, 2009 05:21 PM
10 comments, last by Bregma 15 years, 7 months ago
I don't understand this line:

cd '/home/icecube/boring' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1"
LC_MESSAGES="C" LC_CTYPE="C" gmake -f Makefile.cvs && mkdir '/home/icecube
boring/debug' && cd '/home/icecube/boring/debug' && CXXFLAGS="-O0 -g3" "/home
icecube/boring/configure" --enable-debug=full && cd '/home/icecube/boring
debug' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C"
C_CTYPE="C" gmake -k 



When I start a simple "hello world" project in KDevelop and hit F8 it asks me if I want to run "Automake and friends". I pick yes and then it runs the above command and gives this output:

aclocal
/usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR
/usr/share/aclocal/nspr.m4:8: run info '(automake)Extending aclocal'
/usr/share/aclocal/nspr.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
autoheader
automake
autoconf
configure: WARNING: unrecognized options: --enable-debug
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ld used by gcc... /usr/i486-slackware-linux/bin/ld
checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes
checking for /usr/i486-slackware-linux/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 98304
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/i486-slackware-linux/bin/ld
checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -fPIC
checking if g77 PIC flag -fPIC works... yes
checking if g77 static flag -static works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into programs... immediate
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: executing depfiles commands
configure: WARNING: unrecognized options: --enable-debug
gmake all-recursive
Making all in src
g++ -DHAVE_CONFIG_H -I. -I/home/icecube/boring/src -I.. -O0 -g3 -MT boring.o -MD -MP -MF .deps/boring.Tpo -c -o boring.o /home/icecube/boring/src/boring.cpp
mv -f .deps/boring.Tpo .deps/boring.Po
/bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g3 -o boring boring.o 
mkdir .libs
g++ -O0 -g3 -o boring boring.o 
gmake[2]: Nothing to be done for `all-am'.
*** Success ***



I sort of get some of it. It's running autoconf or something to make a configure file and then it's running configure which uses Makefile.am to make a makefile and then it runs make or something like that. But does anyone understand that long command? I think it's several commands combined into one line but I don't know how to read it. It looks like it first does this: cd '/home/icecube/boring' But then why is that in single quotes? And what is with the following double ampersand? What is this?: WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C"
There are two ways (that I know of, there's probably more [wink]) to separate commands in the shell. ";" and "&&" so "cd foo ; cd bar" executes the "cd foo" command followed by the "cd bar" command. Using "&&" instead means "if the first command fails, don't execute the rest".

So first it does a "cd /home/icecube/boring" and only if that succeeds does it proceed (it'll fail if the directory doesn't exist, for example). Putting the path in single quotes means you're safe if there happens to be a space in there.

The X=Y stuff is setting environment variables. By doing "X=Y gmake ..." it means you set the X variable to "Y" and then execute gmake. The variables are only vaild for as long asthe command is executing.

So to help you understand a bit more, you can break the command up like so:

cd /home/icecube/boring && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C" LC_CTYPE="C" gmake -f Makefile.cvs && mkdir /home/icecube/boring/debug && cd /home/icecube/boring/debug && CXXFLAGS="-O0 -g3" /home/icecube/boring/configure --enable-debug=full && cd /home/icecube/boring/debug && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C" C_CTYPE="C" gmake -k
Advertisement
Hey thanks a lot, man.

So that 2nd command, right after it changes directory, is basically just
make -f Makefile.cvs
(on my computer I think gmake and make are the same thing)

Makefile.cvs just contains this:
default: allall:	aclocal	autoheader	automake	autoconf


I looked up -f in the man pages, all it says it tells make to use the file, so I guess it just acts like a shell script or a DOS .bat file.

I tried just spawning a new hello world program in KDevelop but I didn't hit F8 or run Automake or anything. Instead I just went to the directory in a shell and did this:

aclocal
autoheader
automake
autoconf
./configure
make

And that made my hello world program just fine. I wonder what all those LC_MESSAGES="C" commands are for if they aren't even necessary?

Now I'm trying to figure out what aclocal and all those programs actually do.

[Edited by - icecubeflower on March 23, 2009 9:07:09 PM]
I generated an SDL program in KDevelop instead of just a hello world program and then I added these as linker flags:
-lGL -lSDL_mixer -lGLU -lSDL_image

That should make it run Automake and friends and compile just like my main project. The output was almost exactly the same except for the LDFLAGS at the start and some -lGl and stuff at the bottom.

I wonder how it figures out where all my SDL.h and GL.h files are? I know everybody's computer is different.

I'm trying to get a basic understanding of this stuff. I found out that aclocal needs a "configure.in". I want to see if I can get to the point where I don't need KDevelop to magically generate a configure.in for me. I want to see if I can write those basic files myself and use aclocal and automake and everything myself to generate a makefile. I don't know if this is going to be really hard or really easy.

cd '/home/icecube/boring' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1"LC_MESSAGES="C" LC_CTYPE="C" gmake -f Makefile.cvs && cd '/home/icecube/boringdebug' && LDFLAGS="-lGL -lSDL_mixer -lGLU -lSDL_image" CXXFLAGS="-O0 -g3" "/homeicecube/boring/configure" --enable-debug=full && cd '/home/icecube/boringdebug' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C"LC_CTYPE="C" gmake -k aclocalconfigure.in:12: warning: underquoted definition of KDE_FIND_PATHconfigure.in:12: run info '(automake)Extending aclocal'configure.in:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocalautoheaderautomakeautoconfconfigure: WARNING: unrecognized options: --enable-debugchecking for a BSD-compatible install... /usr/bin/ginstall -cchecking whether build environment is sane... yeschecking for a thread-safe mkdir -p... /usr/bin/mkdir -pchecking for gawk... gawkchecking whether make sets $(MAKE)... yeschecking for g++... g++checking for C++ compiler default output file name... a.outchecking whether the C++ compiler works... yeschecking whether we are cross compiling... nochecking for suffix of executables... checking for suffix of object files... ochecking whether we are using the GNU C++ compiler... yeschecking whether g++ accepts -g... yeschecking for style of include used by make... GNUchecking dependency style of g++... gcc3checking build system type... i686-pc-linux-gnuchecking host system type... i686-pc-linux-gnuchecking for gcc... gccchecking whether we are using the GNU C compiler... yeschecking whether gcc accepts -g... yeschecking for gcc option to accept ISO C89... none neededchecking dependency style of gcc... gcc3checking for a sed that does not truncate output... /usr/bin/sedchecking for grep that handles long lines and -e... /usr/bin/grepchecking for egrep... /usr/bin/grep -Echecking for ld used by gcc... /usr/i486-slackware-linux/bin/ldchecking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yeschecking for /usr/i486-slackware-linux/bin/ld option to reload object files... -rchecking for BSD-compatible nm... /usr/bin/nm -Bchecking whether ln -s works... yeschecking how to recognize dependent libraries... pass_allchecking how to run the C preprocessor... gcc -Echecking for ANSI C header files... yeschecking for sys/types.h... yeschecking for sys/stat.h... yeschecking for stdlib.h... yeschecking for string.h... yeschecking for memory.h... yeschecking for strings.h... yeschecking for inttypes.h... yeschecking for stdint.h... yeschecking for unistd.h... yeschecking dlfcn.h usability... yeschecking dlfcn.h presence... yeschecking for dlfcn.h... yeschecking how to run the C++ preprocessor... g++ -Echecking for g77... g77checking whether we are using the GNU Fortran 77 compiler... yeschecking whether g77 accepts -g... yeschecking the maximum length of command line arguments... 98304checking command to parse /usr/bin/nm -B output from gcc object... okchecking for objdir... .libschecking for ar... archecking for ranlib... ranlibchecking for strip... stripchecking if gcc supports -fno-rtti -fno-exceptions... nochecking for gcc option to produce PIC... -fPICchecking if gcc PIC flag -fPIC works... yeschecking if gcc static flag -static works... nochecking if gcc supports -c -o file.o... yeschecking whether the gcc linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yeschecking whether -lc should be explicitly linked in... nochecking dynamic linker characteristics... GNU/Linux ld.sochecking how to hardcode library paths into programs... immediatechecking whether stripping libraries is possible... yeschecking if libtool supports shared libraries... yeschecking whether to build shared libraries... yeschecking whether to build static libraries... yesconfigure: creating libtoolappending configuration tag "CXX" to libtoolchecking for ld used by g++... /usr/i486-slackware-linux/bin/ldchecking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yeschecking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yeschecking for g++ option to produce PIC... -fPICchecking if g++ PIC flag -fPIC works... yeschecking if g++ static flag -static works... nochecking if g++ supports -c -o file.o... yeschecking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yeschecking dynamic linker characteristics... GNU/Linux ld.so(cached) (cached) checking how to hardcode library paths into programs... immediateappending configuration tag "F77" to libtoolchecking if libtool supports shared libraries... yeschecking whether to build shared libraries... yeschecking whether to build static libraries... yeschecking for g77 option to produce PIC... -fPICchecking if g77 PIC flag -fPIC works... yeschecking if g77 static flag -static works... nochecking if g77 supports -c -o file.o... yeschecking whether the g77 linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yeschecking dynamic linker characteristics... GNU/Linux ld.so(cached) (cached) checking how to hardcode library paths into programs... immediatechecking for sdl-config... /usr/bin/sdl-configconfigure: creating ./config.statusconfig.status: creating Makefileconfig.status: creating src/Makefileconfig.status: creating config.hconfig.status: executing depfiles commandsconfigure: WARNING: unrecognized options: --enable-debuggmake all-recursiveMaking all in srcg++ -DHAVE_CONFIG_H -I. -I/home/icecube/boring/src -I.. -I/usr/include/SDL-D_GNU_SOURCE=1 -D_REENTRANT -O0 -g3 -MT boring.o -MD -MP -MF .deps/boring.Tpo-c -o boring.o /home/icecube/boring/src/boring.cppmv -f .deps/boring.Tpo .deps/boring.Po/bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g3 -R/usr/lib -lGL-lSDL_mixer -lGLU -lSDL_image -o boring boring.o -L/usr/lib -Wl,-rpath,/usr/lib-lSDL -lpthread mkdir .libsg++ -O0 -g3 -o boring boring.o -Wl,-rpath -Wl,/usr/lib /usr/lib/libGL.so -L/usrX11R6/lib /usr/lib/libSDL_mixer.so -L/usr/lib -lGLU /usr/lib/libSDL_image.so-lpng /usr/lib/libtiff.so -ljpeg -lc -lz /usr/lib/libSDL.so -lm /usr/liblibXrandr.so /usr/lib/libXext.so /usr/lib/libXrender.so /usr/lib/libX11.sousr/lib/libxcb-xlib.so /usr/lib/libxcb.so /usr/lib/libXau.so /usr/liblibXdmcp.so -ldl -lvga -lpthread -Wl,--rpath -Wl,/usr/libgmake[2]: Nothing to be done for `all-am'.*** Success ***
It looks like to use those four programs, aclocal, autoheader, automake, and autoconf, you have to have these 3 files:
configure.in
Makefile.am
ltmain.sh

Is that really true or am I understanding it wrong? I copied all 50+ .h and .cpp files from my main project into a new directory. Then I generated a new SDL project in KDevelop in a dummy directory.

I copied those three files KDevelop generated in the dummy directory to the new directroy.

Then I did:
aclocal
autoheader

Then I did:
automake --add-missing
and it added a whole lot of files that I didn't bother copying.

Then I did:
autoconf
LDFLAGS="-lGL -lSDL -lSDL_mixer -lGLU -lSDL_image" ./configure
make

That worked just fine. I compiled my main project without KDevelop. Except for those three files that I copied.

configure.in becomes huge when you generate an SDL project as opposed to a hello world project.

Also ltmain.sh is huge and I have no idea what it is.

Also the makefile doesn't mention any of my .h or .cpp files anywhere. I don't even understand how it works. When I learned about makefiles you gave them rules and told it which files would have to be recompiled if another one was modified. But this makefile works some different way.

Does the configure.in really have to be that huge? What the hell is ltmain.sh?

The way I see it, if I wanted to make a program just for myself, I could write my own makefile by hand. But KDevelop is trying to write a configure.in file that will generate a makefile that will work on anything. FreeBSD, Solaris, Slackware, anything. And that's why it's so huge.

Is that right? Does anybody actually write configure.in and stuff manually?

Because those files are insane. I would spend as much time writing configure.in as I would programming.
Quote: Original post by icecubeflower
The way I see it, if I wanted to make a program just for myself, I could write my own makefile by hand. But KDevelop is trying to write a configure.in file that will generate a makefile that will work on anything. FreeBSD, Solaris, Slackware, anything. And that's why it's so huge.
That's pretty much it, yeah.

You can write the configure.in file yourself (typically, if you were writing one by hand you'd start off when your project was small and had only basic requirements and it would grow as your project's requirements and dependenices, etc grew.)

One of the goals of autoconf/automake is actually to simplify the construction of Makefiles. The files output by KDevelop are quite probably far from "minimal" :-)

I haven't read of all this but it seems to explain things in quite a bit of detail.
Advertisement
Yeah automake/autoconf are great at creating a makefile.

But what is creating that configure.in file that I get when KDevelop generates a new SDL program? Is that just a hard-coded template in KDevelop or is it generating it with a program similar to automake?

The generated configure.in for a hello world program is pretty short. The configure.in for an SDL program is about 9 times as big. And almost everything in it seems to be about KDE, not SDL. I don't understand that. You don't have to run my program in KDE, you just have to have X running. I think about half of this file could be cut but I don't really understand it well enough to do that.

And I still don't see why I need an ltmain.sh file.

configure.in for an SDL program:
AC_INIT(configure.in)AM_CONFIG_HEADER(config.h)AM_INIT_AUTOMAKE(boring, 0.1)AC_LANG_CPLUSPLUSAC_PROG_CXXAM_PROG_LIBTOOLdnl KDE_FIND_PATH(programm-name, variable-name, list of directories,dnl     if-not-found, test-parameter)AC_DEFUN(KDE_FIND_PATH,[   AC_MSG_CHECKING([for $1])   if test -n "$$2"; then        kde_cv_path="$$2";   else        kde_cache=`echo $1 | sed 'y%./+-%__p_%'`        AC_CACHE_VAL(kde_cv_path_$kde_cache,        [        kde_cv_path="NONE"        dirs="$3"        kde_save_IFS=$IFS        IFS=':'        for dir in $PATH; do          dirs="$dirs $dir"        done        IFS=$kde_save_IFS        for dir in $dirs; do          if test -x "$dir/$1"; then            if test -n "$5"            then              evalstr="$dir/$1 $5 2>&1 "              if eval $evalstr; then                kde_cv_path="$dir/$1"                break              fi            else                kde_cv_path="$dir/$1"                break            fi          fi        done        eval "kde_cv_path_$kde_cache=$kde_cv_path"        ])      eval "kde_cv_path=\"`echo '$kde_cv_path_'$kde_cache`\""   fi   if test -z "$kde_cv_path" || test "$kde_cv_path" = NONE; then      AC_MSG_RESULT(not found)      $4   else      AC_MSG_RESULT($kde_cv_path)      $2=$kde_cv_path   fi])KDE_FIND_PATH(sdl-config, LIBSDL_CONFIG, [${prefix}/bin ${exec_prefix}/bin /usr/local/bin /opt/local/bin], [  AC_MSG_WARN([Could not find libsdl anywhere, check http://www.sdl.org])])if test -n "$LIBSDL_CONFIG"; then     LIBSDL_LIBS="`$LIBSDL_CONFIG --libs`"     LIBSDL_RPATH=     for args in $LIBSDL_LIBS; do          case $args in            -L*)               LIBSDL_RPATH="$LIBSDL_RPATH $args"               ;;          esac     done     LIBSDL_RPATH=`echo $LIBSDL_RPATH | sed -e "s/-L/-R/g"`     LIBSDL_CFLAGS="`$LIBSDL_CONFIG --cflags`"     AC_DEFINE_UNQUOTED(HAVE_LIBSDL, 1, [Defines if your system has the LIBSDL library])fiAC_SUBST(LIBSDL_LIBS)AC_SUBST(LIBSDL_CFLAGS)AC_SUBST(LIBSDL_RPATH)AC_OUTPUT(Makefile src/Makefile)
I'd say most of that stuff is just a hard-coded KDevelop template (certainly, the KDE_FIND_PATH stuff could be simplified - most of the time you'd expect sdl-config to be on the path).

To be honest, I haven't done any autoconf stuff in a while, though, so it's getting a bit advanced for me now :-)
What if I wasn't using a fancy IDE? What if I was using jpico? Suppose I had open like four terminal windows. In one I'm writing my program with jpico and hitting <ctrl>-O all the time to save. In another terminal I'm in the same directory typing "make" over and over. Say I've been making up my own simple makefile that works on my computer. But now my massive project is nearing completion and I want people on other systems to be able to do the whole ./configure, make, make install thing on their own computers where my makefile might not work.

How would I go about creating a configure.in? What do the pros do? Or do they all use a fancy IDE?
Quote: almost everything in it seems to be about KDE, not SDL. I don't understand that. You don't have to run my program in KDE, you just have to have X running.


It doesn't have anything to do with KDE. The function just happens to be named KDE_FIND_PATH. It's a function that searches for a library in a set of directories.

Same goes for ltmain.sh. It's a generalized script (much like a complete Makefile) that helps you build libraries using libtool.

Quote: I wonder what all those LC_MESSAGES="C" commands are for if they aren't even necessary?


They change your default language to "C" for the next command, which is the source language of whatever command/application you are using (usually US English). But it can be a different language if the application was written in a different language. It's probably just extra protection in case you're running a weird default language on your system like Chineese or Korean.

To learn more about LC_MESSAGES you need to learn more about gettext, the default localisation and internationalisation library on Linux.

<hr />
Sander Marechal<small>[Lone Wolves][Hearts for GNOME][E-mail][Forum FAQ]</small>

This topic is closed to new replies.

Advertisement