Re: why is gtk install so difficult?
On Thu, 2003-10-16 at 11:13, Chad A Daelhousen wrote: > In that case, is there any situation in which /usr/bin/pkg-config should > NOT look in /usr/local/lib/pkgconfig? Havoc, as maintainer, what are > your thoughts? Should this be changed? /usr/local/lib isn't in /etc/ld.so.conf either (pkgconfig should have an /etc/pkgconfig.conf, though right now it's hardcoded). I don't believe listing /usr/local is always what you want; e.g. I run in either my special-prefix environment or the stock /usr environment from RPMs on the same machine, and if in the stock /usr environment I do *not* want it contaminated with libs from the special prefix. When it comes down to it, to use /usr/local or any other prefix you are going to have to understand --prefix, PATH, LD_LIBRARY_PATH, and so forth. I'm not sure PKG_CONFIG_PATH adds to that burden much, it seems to me the right thing is for pkgconfig to work in exactly the same way as those other things. There's really just one trick to learn, which is to have a script like the one I've posted that sets up the paths. jhbuild even comes with "jhbuild run" to do this. Then to use the stuff in your prefix you do "myscript appname" and to use normal appname you omit the script. I would say someone who doesn't understand this is probably expecting to install GTK with no args to configure and have it replace their system GTK. So at that point magically building things vs. /usr/local is hardly going to save them. The solution would probably be to default to --prefix=/usr --sysconfdir=/etc. Probably installing to overwrite your system stuff is a bad idea, but it's what Owen usually suggests as the simplest thing. >From my standpoint on the receiving end of lots of bug reports, I'd really prefer a rule like "if you don't know shell scripting, basic UNIX, some C programming, don't try building your own software" ;-) The source-based distributions and people randomly hosing up binary-based distributions with their own compiles are a big source of user error bugs. "XYZ randomly acts weird/segfaults/etc." You really do have to understand things to be building from source. Re: /usr/local, an interesting observation - I broke the /usr/local case in dbus for a while and nobody noticed. Almost all developers specify --prefix instead of leaving configure with no args. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
Hi Sven Neumann wrote: Looks like for whatever reason libexpat (used by fontconfig) is not found in your library search path. What does that mean? Fontconfig must have found it during compilation, because the reason I installed expat was fontconfig refusing to compile without it. It's in /usr/lib by the way and everything else seems to find it. The version of expat in Woody-r1 is 1.95.2-6 (probably modified from 1.95.2) is that recent enough at all? Thanks busmanus Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
Hi, busmanus <[EMAIL PROTECTED]> writes: > I definitely won't, when I asked this question, I didn't realize it was > 43 kB. Anyway, I had another look at the config.log and it makes some > more sense now, but I'll need some help all the same. Here's what seems > like the key to the problem: > > > configure: In function `main': > configure:15514: warning: unused variable `x_shm_info' > configure:15525: $? = 0 > configure:15528: test -s conftest.o > configure:15531: $? = 0 > configure:15541: result: yes > configure:15747: checking Pango flags > configure:15753: result: -I/usr/local/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/X11R6/include > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -Wl,--export-dynamic -L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0 > -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 > configure:15798: gcc -o conftest -g -O2 -Wall > -I/usr/local/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/X11R6/include -I/usr/local/include/glib-2.0 > -I/usr/local/lib/glib-2.0/include conftest.c -Wl,--export-dynamic > -L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 > -lgmodule-2.0 -ldl -lglib-2.0 >&5 > /usr/local/lib/libpangoxft-1.0.so: undefined reference to > `XML_SetElementHandler' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to > `XML_SetDoctypeDeclHandler' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParserFree' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to > `XML_SetCharacterDataHandler' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ErrorString' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParseBuffer' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParserCreate' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_SetUserData' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_GetErrorCode' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_GetBuffer' > /usr/local/lib/libpangoxft-1.0.so: undefined reference to > `XML_GetCurrentLineNumber' > collect2: ld returned 1 exit status Looks like for whatever reason libexpat (used by fontconfig) is not found in your library search path. Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gdk_pixbuf errors...
Dear Chris, I get that error too, I tried to link them manually by calling ld and putting every .o in the argument but when I go on to compile GDK it has problems finding the .la script for gdk-pixbuf. --Tara On 2003.10.16 18:26 Chris wrote: > /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:1: parse error in VERSION script > collect2: ld returned 1 exit status > make[3]: *** [libgdk_pixbuf-2.0.la] Error 1 > make[3]: Leaving directory `/2/Dino/gtk+-2.2.4/gdk-pixbuf' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/2/Dino/gtk+-2.2.4/gdk-pixbuf' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/2/Dino/gtk+-2.2.4' > make: *** [all-recursive-am] Error 2 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
On 2003.10.16 08:21 Michael L Torrie wrote: > > What if, for example, if a packaged GTK+ 2 was compiled for, > > say, a glibc 2.2 system and someone with a glibc 2.0 system could > > still run GTK+ 2 if it were compiled for glibc 2.0 but the > > packaged GTK+ 2 was not compiled for glibc 2.0. In this case the > > person would need to compile from source. > > I see. What I do is download the source version of the package from my > distro maker (rh in my case) and rebuild the rpms (build my own > packages) for the older system. This is the easiest and cleanest way, > much cleaner than compiling to /usr/local from a tarball. Hi Micheal, the problem is the compiling GTK part. --Tara ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
On 2003.10.16 01:43 [EMAIL PROTECTED] wrote: > > From: Tara Milana [mailto:[EMAIL PROTECTED] > > What if, for example, if a packaged GTK+ 2 was compiled for, > > say, a glibc 2.2 system and someone with a glibc 2.0 system > > could still run GTK+ 2 if it were compiled for glibc 2.0 but > > the packaged GTK+ 2 was not compiled for glibc 2.0. In this > > case the person would need to compile from source. > > Is that likely? For instance, I don't think that debian or RedHat's GTK+ > would suddenly need glibc 2.2 instead of glibc 2.0 between GTK+ 2.2.20 > and > GTK+ 2.2.21. I have no idea what version of glibc is used by any > particular > version of GTK+ on RedHat or Debian in reality. Hi, yes it is likely. --Tara ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
Sven Neumann wrote:
> Hi,
>
> busmanus <[EMAIL PROTECTED]> writes:
>> I did take a look, but it wasn't written in a language I
>> understand. I cannot quote it in now, but when I do, I'd like to
>> know, if I can send the whole file, or I'll have to try to find the
>> sections in it that may be of significance.
>
>
>
> Please don't send the whole file. The significant part is probably
> right at the bottom.
I definitely won't, when I asked this question, I didn't realize it was
43 kB. Anyway, I had another look at the config.log and it makes some
more sense now, but I'll need some help all the same. Here's what seems
like the key to the problem:
configure: In function `main':
configure:15514: warning: unused variable `x_shm_info'
configure:15525: $? = 0
configure:15528: test -s conftest.o
configure:15531: $? = 0
configure:15541: result: yes
configure:15747: checking Pango flags
configure:15753: result: -I/usr/local/include/pango-1.0
-I/usr/include/freetype2 -I/usr/X11R6/include
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-Wl,--export-dynamic -L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
configure:15798: gcc -o conftest -g -O2 -Wall
-I/usr/local/include/pango-1.0 -I/usr/include/freetype2
-I/usr/X11R6/include -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include conftest.c -Wl,--export-dynamic
-L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0 >&5
/usr/local/lib/libpangoxft-1.0.so: undefined reference to
`XML_SetElementHandler'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to
`XML_SetDoctypeDeclHandler'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParserFree'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to
`XML_SetCharacterDataHandler'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ErrorString'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParseBuffer'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_ParserCreate'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_SetUserData'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_GetErrorCode'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to `XML_GetBuffer'
/usr/local/lib/libpangoxft-1.0.so: undefined reference to
`XML_GetCurrentLineNumber'
collect2: ld returned 1 exit status
configure:15801: $? = 1
configure: failed program was:
#line 15778 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char pango_context_new ();
int
main ()
{
pango_context_new ();
;
return 0;
}
configure:15815: error:
*** Can't link to Pango. Pango is required to build
*** GTK+. For more information see http://www.pango.org
Do you think I should try recompiling pango without xft support or is
there some workaround to the problem? Anyway, how can I remove the
xft-specific pango files from /usr/local without damaging other
packages? Is it my (troublesome) fontconfig-xft installation that messed
up things, or are there other possibilities?
Thanks
busmanus
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: [gtkmm] Custom TreeStore Problems
[EMAIL PROTECTED] wrote: In this case, I am not convinced that enough research has been done to fix the original performance problem. People don't seem to have this problem with GTK+, and Daniel didn't seem to have this problem with gtkmm in regexxer. If someone can show that it's a gtkmm-specific problem then I would like to investigate that. I performed some simple comparisons between GTK+ and gtkmm ListStore performance, and came up with the following numbers (this is on a 2.4GHz P4): append (ms) - rows 1001k 10k 100k GTK+ 1.312 120170 gtkmm 4.439 390900 traverse (ms) - rows 1001k 10k 100k GTK+ .050 .35 3.233 gtkmm .15 1.111 101 So it appears that both scale similarly and roughly linearly, but that gtkmm consistently has a ~4x overhead on append and ~3x overhead on traverse. So judging from those, admittedly rather naïve, measurements, it appears that it migh not be a gtkmm-specific problem other than that the overhead would cause exponential-time operations to become unacceptable much earlier in gtkmm compared to GTK+. The TreeIter is a forward-only iterator and the TreePath operations, although having a random-access interface, are internally implemented using g_slist_nth(), which is linear time. Sort will thus essentially be exponential time. That's pretty bad, because sort is a basic functionality of a TreeView, and because the TreeView itself essentially makes a lot of random accesses to its TreeModel. As this is a GTK+ problem rather than a gtkmm-problem, I put the GTK+ list on copy. -- Christer Palm ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Install Probs
Hi Guys,
I have copied the output of the ./configure i run got GTK+1.2.8. Let me know if you
can help me trace the error here. Thx a lot.
I get this error although GLIB installs fine
bash-2.03$ ./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) no
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking host system type... sparc-sun-solaris2.8
checking build system type... sparc-sun-solaris2.8
checking for ranlib... (cached) :
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... (cached) no
checking for BSD-compatible nm... (cached) /usr/ccs/bin/nm -p
checking whether ln -s works... (cached) yes
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... (cached) no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
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 ... no
checking if gcc static flag -static works... -static
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking whether the linker (/usr/ccs/bin/ld) supports shared libraries... yes
checking command to parse /usr/ccs/bin/nm -p output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/ccs/bin/ld option to reload object files... -r
checking dynamic linker characteristics... solaris2.8 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... sparc-sun-solaris2.8
checking whether build environment is sane... yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for POSIXized ISC... no
checking for gcc option to accept ANSI C... none needed
checking for a BSD compatible install... ./install-sh -c
checking whether make sets ${MAKE}... (cached) no
checking for mawk... no
checking for gawk... no
checking for nawk... nawk
checking for perl5... no
checking for perl... perl
checking for indent... no
checking whether make is GNU Make... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for working const... yes
checking for inline... inline
checking for off_t... yes
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for unistd.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking for argz.h... no
checking for limits.h... yes
checking for locale.h... yes
checking for nl_types.h... yes
checking for malloc.h... yes
checking for string.h... yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getcwd... yes
checking for munmap... yes
checking for putenv... yes
checking for setenv... no
checking for setlocale... yes
checking for strchr... yes
checking for strcasecmp... yes
checking for strdup... yes
checking for __argz_count... no
checking for __argz_stringify... no
checking for __argz_next... no
checking for stpcpy... no
checking for LC_MESSAGES... yes
checking whether NLS is requested... yes
checking for libintl.h... yes
checking for dgettext in libc... yes
checking for msgfmt... /usr/bin/msgfmt
checking for dcgettext... yes
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
found xgettext program is not GNU xgettext; ignore it
checking for catalogs to be installed... ca cs da de el es et eu fi fr ga gl hr hu it
ja ko lt nl no nn pl pt pt_BR ro ru sk sl sv uk wa zh_TW.Big5
checking for extra flags to get ANSI library prototypes... none needed
checking for extra flags for POSIX compliance... none needed
checking for glib-config... /scratch/users/ukoul/Ethereal/glib-1.2.8/glib-config
checking for GLIB - version >= 1.2.8... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GLIB was incorrectly installed
***
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
busmanus wrote: When I am trying to configure the source code of gtk+-2.2.0, I get the following error: checking X11/extensions/XShm.h... yes checking Pango flags... -I/usr/local/include/pango-1.0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -Wl,--export-dynamic -L/usr/local/lib -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 configure: error: *** Can't link to Pango. Pango is required to build *** GTK+. For more information see http://www.pango.org debian:/usr/local/src/abiword/gtk+-2.2.0# I recompiled pango at least three times, with LD_LIBRARY_PATH directed to /usr/local/lib, where glib 2.2.0 and almost all dependencies are installed, I installed all the external dependencies, although I originally wanted to keep the earlier versions already on my system, but nothing is of any use. Glib 2.2.0, pango 1.2.0 an atk 1.2.0 compile fine, and the configure script for gtk finds them all first, but a few hundred lines later it ends up all the same with this very error message. I even thought that I may have linked pango statically by accident, but the help of the pango configure script writes, that dinamic linking is the default, and I am sure I didn't change that. I was trying some of the suggestions in your archive, but they didn't help, although some cases looked quite similar at first sight. I am not a developer, I basically got into this compilation business because of some multilingual software that depends on the new stable gtk. My system is Debian Woody r1 on an old Pentium I (MMX) at 225 MHz. Can any of you help? If my memory is not lying I had a similar problem some time ago - the reason was freetype library. I had a new headers and lib in /usr/X11R6 and old ones in /usr. Check this out and remove old version. Hope this help. Olexiy ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
gdk_pixbuf errors...
Hello, I am having some errors that I have no idea what they are. I have pango 1.2.5, glib-2.2.3, atk-1.2.4 installed. Those installed without a hitch. Now when I try to `make` gtk+ I get the error: - gcc -shared .libs/gdk-pixbuf.o .libs/gdk-pixbuf-animation.o .libs/gdk-pixbuf-data.o .libs/gdk-pixbuf-io.o .libs/gdk-pixbuf-loader.o .libs/gdk-pixbuf-scale.o .libs/gdk-pixbuf-util.o .libs/gdk-pixdata.o .libs/gdk-pixbuf-enum-types.o -Wl,--whole-archive pixops/.libs/libpixops.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib /usr/local/lib/libgmodule-2.0.so -ldl /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so -ltiff /usr/local/lib/libjpeg.so -lpng12 -lz -lm -Wl,--export-dynamic -Wl,-soname -Wl,libgdk_pixbuf-2.0.so.0 -Wl,-version-script -Wl,.libs/libgdk_pixbuf-2.0.ver -o .libs/libgdk_pixbuf-2.0.so.0.200.4 /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:1: parse error in VERSION script collect2: ld returned 1 exit status make[3]: *** [libgdk_pixbuf-2.0.la] Error 1 make[3]: Leaving directory `/2/Dino/gtk+-2.2.4/gdk-pixbuf' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/2/Dino/gtk+-2.2.4/gdk-pixbuf' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/2/Dino/gtk+-2.2.4' make: *** [all-recursive-am] Error 2 - I am more than happy to provide more information, but I'm not sure what anyone needs from as yet. Thanks, Chris- -- Time is the coin of your life. It is the only coin you get, and only you can determine how it can be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
Hi, busmanus <[EMAIL PROTECTED]> writes: > The download page still shows version 2.2.0 as the latest stable > version, at least that's what I made out of it. What page is that? http://gtk.org/download/ says 2.2 is the latest version and it links to ftp://ftp.gtk.org/pub/gtk/v2.2/. At the beginning of the file listing you can see the latest released versions in the stable 2.2 series. > I did take a look, but it wasn't written in a language I > understand. I cannot quote it in now, but when I do, I'd like to > know, if I can send the whole file, or I'll have to try to find the > sections in it that may be of significance. Please don't send the whole file. The significant part is probably right at the bottom. Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
On Thu, 2003-10-16 at 03:03, Tara Milana wrote: > On 2003.10.16 00:33 [EMAIL PROTECTED] wrote: > > > You only have to update the dependencies if you have to update the > > dependencies. If a new GTK+ version requires updated dependencies then > > you'll have the same problem when building from source, except it will be > > more difficult. > > Hi, > > What if, for example, if a packaged GTK+ 2 was compiled for, > say, a glibc 2.2 system and someone with a glibc 2.0 system could > still run GTK+ 2 if it were compiled for glibc 2.0 but the > packaged GTK+ 2 was not compiled for glibc 2.0. In this case the > person would need to compile from source. I see. What I do is download the source version of the package from my distro maker (rh in my case) and rebuild the rpms (build my own packages) for the older system. This is the easiest and cleanest way, much cleaner than compiling to /usr/local from a tarball. Michael > > --Tara > ___ > gtk-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gtk-list -- Michael L Torrie <[EMAIL PROTECTED]> ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
Hi, Chad A Daelhousen <[EMAIL PROTECTED]> writes: > Oh, I misunderstood the problem. /usr/bin/pkg-config is _still there_, > oblivious to /usr/local/*, and run by default because it's earlier in > $PATH. > > In that case, is there any situation in which /usr/bin/pkg-config should > NOT look in /usr/local/lib/pkgconfig? Havoc, as maintainer, what are > your thoughts? Should this be changed? Yes, pkg-config should never look into any other prefix than the one it was installed to. Unless of course you tell it so by setting your PKG_CONFIG_PATH. Please check the xdg-list archives. This has been discussed there in full length (the thread starts with https://listman.redhat.com/archives/xdg-list/2003-September/msg00106.html). Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-2.2.0 ./configure error about pango 1.2.0
Sven Neumann wrote: > Hi, > > busmanus <[EMAIL PROTECTED]> writes: > > >> When I am trying to configure the source code of gtk+-2.2.0, > > > > Is there a special reason you are compiling gtk+-2.2.0 instead of the > newer gtk+-2.2.4? You should always use the latest released versions > in the stable series (glib-2.2.3, pango-1.2.5, atk-1.2.4, gtk+-2.2.4). The download page still shows version 2.2.0 as the latest stable version, at least that's what I made out of it. I simply didn't feel like experimenting with the development version. Another reason is, that I read something about abiword-2.0.0 not liking later versions very much, but I don't remember clearly what other version was mentioned there. The third and most pressing reason is that I have a rather slow modem internet connection through the most expensive telefon line provider of the world (at least some say so). > Take a look at config.log to find out why exactly the linking fails. I did take a look, but it wasn't written in a language I understand. I cannot quote it in now, but when I do, I'd like to know, if I can send the whole file, or I'll have to try to find the sections in it that may be of significance. Thanks busmanus Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
At Wed, Oct 15, 2003 at 09:26:46AM -0400, Paul Davis wrote:
> >At Tue, Oct 14, 2003 at 11:47:12PM -0600, Michael Torrie wrote:
> >> All the compilation problems I've seen lately on this list stem from
> >> users not understanding what happens when you install to /usr/local and
> >> try to use pkg-config without telling it to look for your .pc files in
> >> /usr/local/lib/pkgconfig (it defaults to /usr/lib/pkgconfig).
> >
> >That suggests pkg-config needs ${PREFIX}/lib/pkgconfig included in its
> >default path. It's not user error if a piece of software doesn't pay
> >attention to where it installed itself (or was asked to install itself).
>
> that's not what is happening in such situations. linux (and unix in
> general) has been plagued by two different installation
> conventions. "system installs" go into /usr, "user installs" go into
> /usr/local. with the dawn of package systems like RPM, deb etc., most
> of them default to an install in /usr. if the user then installs
> something from a source tarball, it normally ends up in
> /usr/local. this is modelled on some old ideas about backups, system
> reinstalls and so forth that often no longer apply.
Oh, I misunderstood the problem. /usr/bin/pkg-config is _still there_,
oblivious to /usr/local/*, and run by default because it's earlier in
$PATH.
In that case, is there any situation in which /usr/bin/pkg-config should
NOT look in /usr/local/lib/pkgconfig? Havoc, as maintainer, what are
your thoughts? Should this be changed?
--
Chad Daelhousen
My opinions are my own, until UB purchases my soul.
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
scrolledwindow auto scroll!
Hi, I am using a scrolledwindow and want to know how to automatically make the scrollbars especially the vertical, position itself such that the last widget set active or which is currently grabbing the focus is always visible at the bottom of the scrolled window. Or in case of text widgets, the last item inserted into the text entry (within the scrolled window) is always visible at the bottom of the scrolled window. How can I implement this behavior? Any help, comments, examples, would be highly appreciated Thanks in advance, david __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
RE: why is gtk install so difficult?
> From: Tara Milana [mailto:[EMAIL PROTECTED] > What if, for example, if a packaged GTK+ 2 was compiled for, > say, a glibc 2.2 system and someone with a glibc 2.0 system > could still run GTK+ 2 if it were compiled for glibc 2.0 but > the packaged GTK+ 2 was not compiled for glibc 2.0. In this > case the person would need to compile from source. Is that likely? For instance, I don't think that debian or RedHat's GTK+ would suddenly need glibc 2.2 instead of glibc 2.0 between GTK+ 2.2.20 and GTK+ 2.2.21. I have no idea what version of glibc is used by any particular version of GTK+ on RedHat or Debian in reality. If the packages are broken then the packages should be fixed. That's not a building-from-source problem. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: why is gtk install so difficult?
On 2003.10.16 00:33 [EMAIL PROTECTED] wrote: > You only have to update the dependencies if you have to update the > dependencies. If a new GTK+ version requires updated dependencies then > you'll have the same problem when building from source, except it will be > more difficult. Hi, What if, for example, if a packaged GTK+ 2 was compiled for, say, a glibc 2.2 system and someone with a glibc 2.0 system could still run GTK+ 2 if it were compiled for glibc 2.0 but the packaged GTK+ 2 was not compiled for glibc 2.0. In this case the person would need to compile from source. --Tara ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
RE: why is gtk install so difficult?
> From: Tara Milana [mailto:[EMAIL PROTECTED] > Sometimes packages aren't always an option for everyone. If > you package something then you require whoever uses it to > get/update everything it depends on. Where as source is more > convient without having to do that. You only have to update the dependencies if you have to update the dependencies. If a new GTK+ version requires updated dependencies then you'll have the same problem when building from source, except it will be more difficult. Basically, you don't make something easier by doing it the difficult way - it's just more difficult. Somebody in this thread suggested that the install should automatically download the source of the dependencies and install them too. Of course that would wreck any binary installation. It's OK in a separate prefix, but garnome already does that for you, and the gentoo distro is all source all of the time for people who think that's fun. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
