Extension Development :: gtk+-2.12.9

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)

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

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

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.

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.

Next Page...
original here.