LinuxQuestions.org - A good practice for compiling?

- Mandriva (https://www.linuxquestions.org/questions/mandriva-30/)

- - A good practice for compiling? (https://www.linuxquestions.org/questions/mandriva-30/a-good-practice-for-compiling-212592/)

Quote:

Originally posted by whansard
do
configure --prefix=/usr

That will end up with exactly the same result.

You need the development libraries for GTK1.

Do you have a /usr/include/gtk-1.x or /usr/local/include/gtk-1.x directory?

If not then you need to install GTK1 development package, libgtk+1.2-devel looks like the one (I don't use mandrake, so can not say 100%).

Quote:

Originally posted by slyman
That will end up with exactly the same result.

You need the development libraries for GTK1.

Do you have a /usr/include/gtk-1.x or /usr/local/include/gtk-1.x directory?

If not then you need to install GTK1 development package, libgtk+1.2-devel looks like the one (I don't use mandrake, so can not say 100%).

I think I have it. Check it out:

Code:

[ken@localhost include]$ ls g*.*

gammadialog.h  gconv.h  getopt.h  glob.h  gnu-versions.h  grp.h



glib-1.2:

glib.h  gmodule.h



glib-2.0:

glib/  glib.h  glib-object.h  gmodule.h  gobject/



gtk-2.0:

gdk/  gdk-pixbuf/  gdk-pixbuf-xlib/  gtk/



gtkspell-2.0:

gtkspell/

Quote:

nope. the default prefix on most systems is /usr/local for compiled apps. and gtk apps are stubborn about needing the same prefix as gtk.

Quote:

Originally posted by whansard
nope. the default prefix on most systems is /usr/local for compiled apps. and gtk apps are stubborn about needing the same prefix as gtk.

So what do I do then to get this to work?

there are going to be many packages that you will need probably. don't get worked up. i was only arguing above about the default installation location. if either of us is right, run
configure --prefix=/usr
post the error message at the end, and we'll get the next thing, which is probably libgtk+1.2-devel.

Quote:

Originally posted by whansard
there are going to be many packages that you will need probably. don't get worked up. i was only arguing above about the default installation location. if either of us is right, run
configure --prefix=/usr
post the error message at the end, and we'll get the next thing, which is probably libgtk+1.2-devel.

Here we go:

[ken@localhost xmms-1.2.10]$ ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output... 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 gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for strerror in -lcposix... no
checking whether byte ordering is bigendian... no
checking for inline... inline
checking for an ANSI C-conforming const... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /bin/sed
checking how to recognise dependent libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -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 for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether -lc should be explicitly linked in... no
creating libtool
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for glib-config... /usr/bin/glib-config
checking for GLIB - version >= 1.2.2... yes
checking for gtk-config... no
checking for GTK - version >= 1.2.2... no
*** The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: error: *** GTK+ >= 1.2.2 not installed - please install first ***

:cry:

Where is "gtk-config" on your system?
locate gtk-config

Quote:

Originally posted by david_ross
Where is "gtk-config" on your system?
locate gtk-config

I guess I don't have it:

Code:

[ken@localhost ken]$ locate gtk-config

[ken@localhost ken]$

So then I try:

Code:

[root@localhost ken]# urpmi gtk-config

no package named gtk-config

So you guys getting frustrated yet? This is what I meant when I initially said that I haven't been able to compile ANYTHING, but I want to learn and this is frustrating!!!!! :mad:

maybe your locate database hasn't been updated since you installed gtk-devel. that's what the gtk-config is part of. it should be in /usr/bin/. it's a text file. if you have an older version of gtk installed than that version of xmms wants, you might can try an older version of xmms or you may have to compile a newer version of gtk. 2.0 and up broke compatibility with lower versions, if i remember correctly. the problem is you can mess stuff up on your system trying to do that. i think the glib and gtk versions have to match.

Quote:

Originally posted by whansard
maybe your locate database hasn't been updated since you installed gtk-devel. that's what the gtk-config is part of. it should be in /usr/bin/. it's a text file. if you have an older version of gtk installed than that version of xmms wants, you might can try an older version of xmms or you may have to compile a newer version of gtk. 2.0 and up broke compatibility with lower versions, if i remember correctly. the problem is you can mess stuff up on your system trying to do that. i think the glib and gtk versions have to match.

What do you suggest I do?

I just had this thought that I could uninstall xmms 1.2.7 (my current version), and just URPMI xmms for the more recent 1.2.10 version? I think I'm just going to give up on this compiling business. It just was never meant to be. :cry:

Quote:

Originally posted by whansard
nope. the default prefix on most systems is /usr/local for compiled apps. and gtk apps are stubborn about needing the same prefix as gtk.

No they are not. Sorry.

I use LFS so have compiled EVERYTHING myself. I use /usr/local for testing and anything I want to keep going in /usr.... I have compiled and run many gtk apps to/from /usr/local with gtk in /usr.

I would guess that your PATH, PKG_CONFIG_PATH and/or ld.so.conf is incorrect if you have problems doing this.

Anyhoo...

Micro420, you have the GTK2 dev stuff, but not GTK1. They are different, i.e. GTK1 apps will not compile or run with GTK2 and v v. They can be installed in parrallel.

Install libgtk+1.2-devel like I said in my previous post.

sometimes they do. sorry i was so dismissive of your first post.

http://www.linuxquestions.org/questi...388#post617388

ok what you want to do is go back into the install package thing. In there install the entire development tree. A lot of people skip that because they figure that they won't be developing anything, but it is still needed to compile programs.

Quote:

Originally posted by whansard
sometimes they do. sorry i was so dismissive of your first post.

http://www.linuxquestions.org/questi...388#post617388

No worries, no offence taken I'm a net veteran and take the positive approach to reading posts ;)

I kind of agree with you, but this is a package thing (rpm, dep etc etc) not a glib/gtk etc thing. If the pkgconfig ({,/usr,/usr/X11R6,/usr/local,/opt}/lib/pkgconfig/*.pc etc) files are available through PKG_CONFIG_PATH, the xxxx-config files are in the PATH, {,/usr,/usr/X11R6,/usr/local,/opt}/lib etc are in ld.so.conf and ldconfig has been executed, then all should be ok. There can be problems when something has been built in say /usr/local and moved to /usr because anything that looks for it's component files in it's .pc file will be looking in /usr/local, not /usr.

In other words... if you are compiling anything, I would suggest that you have at least the following in your ~/.profile

PATH="/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin"
PKG_CONFIG_PATH="/usr/lib/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/lib/pkgconfig"

And, at least the following in ld.so.conf (run ldconfig after updating):

/lib
/usr/lib
/usr/X11R6/lib
/usr/local/lib
/opt/lib

Running ldconfig after installing anything cannot hurt, even if it may be unneccesary.

And finally, do not move files around unneccesarily. If you want something in /usr, use ./configure --prefix=/usr, do not copy it from /usr/local

No, the --prefix has nothing to do with where resources are located. --prefix is used for the location of the program you're compiling.

I had a similar problem with avifile, which could not find what was obviously present: qt3! I had to run ./autogen.sh before using ./configure.
Maybe this is the solution for you, too... Good luck!

Yves.