Apache OpenOffice (AOO) Bugzilla – Issue 26463
vcl includes gtk files without checking for them first
Last modified: 2004-09-16 19:26:45 UTC
Hi, my build system doesn't have gtk header files installed. configure doesn't check their existence, but vcl still tries to use them: As a TEMPORARY solution, I use the attached patch the completely removes gtk from vcl.
Created attachment 13789 [details] Remove GTK from the build
set target
cp->pl: probably same thing as the other gtk stuff ... please have a look
Actually you should have the gtk headers by build the gtk project first - on which vcl DOES have a dependency in vcl/prj/build.lst. First question: why did that dependency fail ? Second question: would you still rather have a configure option to switch gtk usage off or should a dependency on the gtk project suffice in principle (if it worked) ?
*** Issue 26468 has been marked as a duplicate of this issue. ***
Project gtk is not in OpenOffice alias thus CVS checkouts do not bring it. So all features using gtk project should be disabled by default. The same way as crashreporter is. gtk is system library thus it is nonsense to distribute it in the sources - so OOo does not contain them. The default should be not using GTK (imagine there will be Qt in the future, XYZ then etc.) and there should configure switch to enable it if you want it. If it is enabled and gtk headers are not found, configure should stop immediatelly and not continue. Just my 2 cents... What do you think?
There is a Qt plugin in development as well AFAIK, though there is not yet code checked in. I'm not sure whether disabling gtk (or Qt) per default is a good idea, but in the end i don't care much as long as the download for the end user contains all vcl plugins. So i guess i whould encapsulate the compilation of gtk code in vcl in some macro GTK_ENABLED. mh: how do i get that set in the configure script ?
lowering prio since workaround is known.
I've checked out the latest one from SRC680_m30, seems like some work around has been applied but it does not work at all. Instead of showing the errors, it now hangs (a whole night) with the following: [root@support vcl]# build build -- version: 1.99 Checking dmake... Using version 4.10 /extra/SRC680_m30/vcl/source/unotypes ------------- /extra/SRC680_m30/vcl/unx/source/src ... /extra/SRC680_m30/vcl/unx/gtk/app And a "top" reveals that: makedepend is eating up all the CPU, apparently in an infinite loop. BTW, instead of check out OpenOffice, I also check out the module "gtk" manually.
Hi, I see the exact same hang in the exact same place. I have added some debug print statements to makedepend but there appears to be an "include loop" that freaks out makedepends but only witht he gtk that comes with OOo. It is also possible that the soltools/mkdepend/def.h hardcoded limits have been reached and that is causing the infinite loop. I will take a closer look. Kevin
Hi, Some further information. The problem seems to be related to specific files in the solver/680/unx*.pro/inc. If I run makedepend manually on change the includes to point to gtk/unxlngppc.pro/inc so that it finds gtk and gdk there instead of in solver/680/unx*.pro/inc then all is fine. I added some debug print statements to makedepend and watched it get slower and slower as it tried to parse things in the solver. So either some file that exists only in the solver is causing trouble or the makedepend is simply not scaling very well to the number of header files that now exist in the solver incl directory. Kevin
Hi, I think the hangs are not actual hangs but instead are simply caused by makedepend not scaling properly when faced with lots of includes as in the gtk/gtk.h and gdk/gdk.h headers. I thik the sheer number of headers found in solver/680/unx*/inc adds to that difficulty. I am not sure what to do about it. Kevin
The dependency tool problem is under investigation by hjs; and it looks like you said, the tool simply chokes on too many files. In the meantime i'm convinced that i should move tiff, libjpeg and libpng to the gtk project, too.
cc for linux sparc
pl->hjs: The underlying problem is fixed with ENABLE_GTK (issue 26570), which leaves the dependency problem in build.lst. Since you're working on that i forward this issue to you.
if "gtk" is an unwanted module on OOo, the first line of "vcl/prj/build.lst" should contain "SO:gtk" instead of "gtk". is this agreed on OOo?
change the dependency to "SO:gtk"
.
Closing.