gtk+-2.12.9


Forum: Extension Development
Topic: gtk+-2.12.9
started by: Jason W

Posted by Jason W on April 12 2008,14:16
I built gtk+-2.12.9 with the latest pango, cairo, freetype, etc and installed it into /opt/gtk+-2.12.9 to make a uci package.  Setting it up in a basic way (echo "/opt/gtk+-2.12.9/lib" >> /etc/ld.so.conf && ldconfig) allows it to work fine with extensions made for the gtk-2.10.9 extension.  One catch - the glib2 files in /usr/lib have to be removed for the gtk extension to work.  ldconfig links files in /opt/gtk+-2.12.9 to the glib2 in /usr/lib if it is there.  I have googled and all advice was to remove the old glib2 if you have 2 versions installed.  I do not want to mess with the base system and I was curious if anyone has had this same issue and was able to resolve it.  Thanks in advance.

JW

Posted by Juanito on April 12 2008,14:50
Did you compile a version of glib2 in /opt/gtk+-2.12.9?

If so then maybe this would work prior to compiling gtk:
Code Sample
$ export PKG_CONFIG_PATH=/opt/gtk+-2.12.9/lib/pkgconfig
or
$ export LDFLAGS=-L/opt/gtk+-2.12.9/lib

- or maybe you could edit the Makefile to point to the correct glib2

Edit: I'm not sure if the version of glib2 you want to use produces a "glib-config" but if it does, you could link this to /opt/bin and see if that helps

Edit2: gimp-2.4.uci uses glib2 & gtk+-2.10.13 so one of the methods above must have worked...

Posted by Jason W on April 13 2008,00:45
I built the latest glib2 in /opt/gtk+-2.12.9.  Turns out glib2 is not the only library having conflicts.  I built this stuff on Sarge with no other gtk2/glib2 present on the system.  Building on DSL of course usually minimizes conflicts.  I did the pkgconfig/LDFLAGS thing when building, but I messed up somewhere.  Any libs that are also in the DSL base system seem to confuse the library linking.  I am wanting a gtk2.uci similar to gtk-2.10.9.unc - preferably 2.12 but 2.10 would do.  I will start over and give it another go.  One more thing, did you build the gimp-2.4 on DSL with the compile-3.3.5.uci extension?  I normally use it, but had some errors compiling glib2.  I was building this on Woody at first at my other place and later built it on Sarge one night here.  Thanks for your help.
Posted by ^thehatsrule^ on April 13 2008,01:58
Quote
Edit: I'm not sure if the version of glib2 you want to use produces a "glib-config" but if it does, you could link this to /opt/bin and see if that helps
Newer builds of glib deprecated glib-config for pkgconfig.  Unfortunately, this will break some things that look for it.

I recently built glib 2.14.6 (latest stable afaik), and I had to include bits/posix1_lim.h (or just define SSIZE_MAX as LONG_MAX).  I'm not sure if this is a correct solution though since I didn't look this up.  Did you have those build errors on your Debian setups?

Posted by Juanito on April 13 2008,03:45
Quote
One more thing, did you build the gimp-2.4 on DSL with the compile-3.3.5.uci extension?  I normally use it, but had some errors

Yes, but I had an error as you say. Inserting the following in giounix.c will fix the error: "`SSIZE_MAX' undeclared":
Code Sample
#ifndef SSIZE_MAX
#define SSIZE_MAX 0x7fffffff
#endif


Quote
Did you have those build errors on your Debian setups?

I gave up building on debian setups, but I do see a number of errors when using compile-3.3.5 - I'm not sure if it is because the extension is in /opt, because some of the headers are old or what. The "`_POSIX_ARG_MAX' undeclared" error pops up from time to time.

Posted by ^thehatsrule^ on April 13 2008,04:47
fyi:
- that hex number and LONG_MAX are the same number when built under DSL with the compile extension
- if you don't want to edit the source, you can just pass -D flags, i.e. -DSSIZE_MAX=LONG_MAX
- the Debian question was meant for Jason W

I think there might be a problem with the compiler setup though.  By looking at the header files, it should be defined.

Compiling a simple test app for related defines worked under Debian with gcc 3.3.5, but didn't work under the compile-3.3.5 setup.  However, if I copy limits.h over to cwd (and then include that instead), everything works.  It seems that the system wide limits.h has certain parts that are ignored.  EDIT: It seems that compiling it with only via sudo works... so it may seem to be a permissions problem? (Doesn't seem to work if you use a 'root' shell though)

Posted by Juanito on April 13 2008,05:33
Quote
However, if I copy limits.h over to cwd (and then include that instead), everything works.  It seems that the system wide limits.h has certain parts that are ignored.

- cwd = current working directory?

I'd noticed that bits of limits.h are ignored, but didn't know why. In fact compile-3.3.5 doesn't throw up too many errors, but they tend to be one of the same four or five errors each time.

Thanks for the "-DSSIZE_MAX=LONGMAX" tip

Posted by ^thehatsrule^ on April 13 2008,06:02
Quote
- cwd = current working directory?
Yes.  It also works it you copy it somewhere else and pass the path via -I

This could not just be limited to limits.h.  Note that I updated my previous post to include some odd findings.

Here's a snippet for a workaround:
Code Sample
cp -a /opt/compile*/include /opt/include
make clean
export CPPFLAGS=-I/opt/include
./configure --prefix=/opt/glib-2.14.6
make install-strip

Posted by Juanito on April 13 2008,09:45
Quote
Here's a snippet for a workaround:...

given that I had:
Code Sample
$ export CPPFLAGS=-I/opt/compile-3.3.5/include

- I must be missing something, but I don't understand what copying the headers to /opt/include and then pointing CPPFLAGS to there changes? [Edit: I see it now, by copying the headers in this way, the permissions are set to dsl.staff and the glib2 error does not occur. Strange that if I set /opt/compile-3.3.5/include permissions to dsl.staff recursively, the error still occurs..]

BTW, "export CFLAGS=-DSSIZE_MAX=LONGMAX" threw up an error about "LONGMAX" not being defined, but "-DSSIZE_MAX=0x7fffffff" worked for me compiling glib2.

Posted by Jason W on April 13 2008,12:05
After given more thought about gtk2+-2.12.9, everything built without error and without linking to any other libraries in the build process.  Issues only come up when running ldconfig after installing gtk2 on DSL.  Earlier versions of Glib2 and Freetype are part of the DSL base system, and those are the two libs that get their wires crossed.  And I think that building the gtk2 suite on DSL would not really solve the problem.  You would link to the right libraries during build time, but get your wires crossed later running ldconfig all the same.  Extensions that contain libraries to be used for just that extension pose no problem even if there are other versions installed in the base system.  The purpose of course with a gtk2.uci is to be able to use it with Firefox and any other app that expects gtk2 to be in a standard,  or at least findable, place.   I think there would be no issues if I just built extensions against the /opt/gtk+-2.12.9 location that would not require using ldconfg after installing gtk2.   But that would not be of much use.  

Correct me if I am wrong on any of this.   Again, thanks for the help and pointers.

Posted by ^thehatsrule^ on April 13 2008,17:44
Quote
BTW, "export CFLAGS=-DSSIZE_MAX=LONGMAX" threw up an error about "LONGMAX" not being defined, but "-DSSIZE_MAX=0x7fffffff" worked for me compiling glib2.
Ah, it should be LONG_MAX.  I guess I typed it out wrong the second time around.  Updated post to reflect the correct define.

Quote
You would link to the right libraries during build time, but get your wires crossed later running ldconfig all the same.  Extensions that contain libraries to be used for just that extension pose no problem even if there are other versions installed in the base system.  The purpose of course with a gtk2.uci is to be able to use it with Firefox and any other app that expects gtk2 to be in a standard,  or at least findable, place.   I think there would be no issues if I just built extensions against the /opt/gtk+-2.12.9 location that would not require using ldconfg after installing gtk2.   But that would not be of much use.
Some ideas:
- you could use a .dsl or .unc like the previous gtk2 extensions
- do some 'magic' with ldconfig or on ld.so.conf (i.e. have your gtk path first)
- set LD_LIBRARY_PATH, i.e. in .xinitrc and tell the user to restart X
- GTK variables (see < http://library.gnome.org/devel/gtk/unstable/gtk-running.html > )

I was looking forward to this extension (to save me a bit of time a well), so it would be nice to see it completed, even if it's not an entirely ideal solution.

Posted by Juanito on April 13 2008,17:56
Any ideas as to why /opt/include with owner dsl.staff will compile glib2 without errors when /opt/compile-3.3.5/include will not, even when changed to dsl.staff?
Posted by Jason W on April 13 2008,18:47
EDIT: Problem solved.
Posted by ^thehatsrule^ on April 13 2008,18:56
Quote
Any ideas as to why /opt/include with owner dsl.staff will compile glib2 without errors when /opt/compile-3.3.5/include will not, even when changed to dsl.staff?
No idea.  What I can conclude is that any include files that are _outside_ of the original include directory will work as expected.

Could be something that was compiled in?  And I'm still not sure why using sudo works in my test. (only `sudo cc mytest.c` works, nothing else seems to)

Posted by Jason W on April 13 2008,19:05
^thhatsrule^,
Putting /opt/gtk+-2.12.9/lib at the beginning of /etc/ld.so.conf did the trick.  I don't know why I didn't try that.  It works perfectly now.  Thanks.

Posted by WDef on April 16 2008,21:39
Phew what an ugly read that was guys.  Some heroic compiling going on there.  Just think what people on distros that actually have all that stuff ready to go are missing!

Anyway great  collective work - so when do we get the gtk+-2 uci?

Can you please just include all the headers so I can build stuff against it?

Posted by Jason W on April 16 2008,23:13
Wdef,
The only glitch left that I can find is antialiasing.  Antialiasing works automatically on the host Debian system but for some reason is not enabled by default when used on DSL.  Hopefully a configuration setting can fix it.  I am checking to make sure nothing is broken.  I am not too familiar at this point with fonts and such.   I will submit what I have tomorrow and hopefully there are not a lot of rough edges to be smoothed out.

EDIT:  On second thought it may take a little longer, since it I shouldn't submit it until antialiasing works.  I am googling and troubleshooting as best I can, but would be glad for some pointers from someone more familiar with fonts.

Posted by Jason W on April 21 2008,01:15
Antialiasing was working all along, just takes the right fonts installed.
Ignorance on my part, as well as lack of time (working ~70 hrs/week).
And any Gtk2 .uci will take either editing /etc/ld.so.conf and/or setting the LD_LIBRARY_PATH.
So on to the finishing touches and submitting.
Firefox 2.0.0.14, Juanito's Gimp-2.4 and many GTK2 extensions built for the gtk2-0705.dsl works well with this.
As well as all made for gtk+-2.10.9.
I will add libfribidi to support Abiword.
Stripped down this is about a 14MB .tar.gz extension so far, so not as big as I thought it would be.

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.