Compilation of unit tests fail on Ubuntu 10.04 due to GTK link issues

[GoogleCodeExporter]

To reproduce, start project:
./fbgen.py
./prepmake.sh
(cd build; make)

Linking fails with message like the following:
Linking CXX executable EXA_UnitTest_NpapiPlugin
../PluginWindow/libEXA_PluginWindow.a(PluginWindowX11.cpp.o): In function 
`FB::PluginWindowX11::PluginWindowX11(FB::WindowContextX11 const&)':
PluginWindowX11.cpp:(.text+0x108): undefined reference to `gtk_plug_new'
PluginWindowX11.cpp:(.text+0x113): undefined reference to `gtk_drawing_area_new'

Use FireBreath commit 2f490e13b2c58a82648db28ed82a7bec172daec6 (HEAD version as 
of 7th Dec 2010).

It appears that the GTK libraries are not being linked into the unit test 
binary and this is confirmed by running 'make VERBOSE=1' - No GTK libraries are 
listed at link stage.

This appears in part to be due to missing GTK_LIBRARIES specification in 
NpapiPluginTest CmakeLists.txt.

A simple patch is attached, although this does not completely fix the issue.  
If FB_DISABLED_GUI is set to 1 in both unit test CMakeLists.txt and 
PluginConfig.cmake, the link still fails in the same manner.  This is because 
the test links against libXXX_PluginWindow.a which has a dependency on GTK 
libraries.

Original issue reported on code.google.com by austin_p...@hotmail.com on 8 Dec 2010 at 7:45

Attachments:

• fb.patch

[GoogleCodeExporter]

There are further issues the prevent compilation with gtk after the first run 
of prepmake.sh.  The problem is that the makefiles generated by prepmake differ 
between the first and second runs due to caching by cmake and the way the 
add_x11_plugin is called.  On the first run through, the GTK_XXX variables are 
not set.  On the second run of prepmake they are preloaded from the cache 
before other rules run.

I've attached a patch but don't know if it's suitable as I haven't delved into 
the project in detail.  The basic changes are:
1. Modify X11.cmake so that the GTK_XXX variables are defined outside of 
add_x11_plugin so that these variables are available even if add_x11_plugin is 
not used.
2. Try to move all FB_GUI_DISABLED config inside the PluginConfig.cmake files.
3. Rework the inclusion order of PluginConfig.cmake and common.cmake.
4. Added FB_GUI_DISABLED item to fbgen generation.

This ensures first that the FB_GUI_DISABLED variable is valid before X11.cmake 
is included.  X11.cmake then uses FB_GUI_DISABLED to appropriately populate 
GTK_XXX variables.

I think the change in inclusion order makes sense anyway because it allows base 
config variables to be configured in PluginConfig.cmake which can then be 
referenced by common cmake rules.

At least for me, compilation now passes on the first compile after prepmake, as 
long as FB_GUI_DISABLED is set consistently between unit test and plugin.

There is still a bug (which I may have introduced) where if FB_GUI_DISABLED is 
set, the resulting plugin is still linked to GTK libraries.

Patch attached.

Austin

Original comment by austin_p...@hotmail.com on 8 Dec 2010 at 1:18

Attachments:

• fb2.patch

[GoogleCodeExporter]

So I had mostly (but not completely) fixed this issue, but it turned out that I 
pushed it to the wrong repository :-P  OOPS!  Anyway, should be fixed now (at 
least it builds for me on all three of my linux boxes).

Thanks for the help!

Original comment by taxilian on 12 Dec 2010 at 8:03

• Changed state: Fixed

[GoogleCodeExporter]

I'm proposing additional changes to those already committed.  The attached 
patch, which should apply cleanly to abf518baef832e2169841247eaf8c6637ab25168 
has a number of other minor changes:

1. The FB_GUI_DISABLED is now only in the PluginConfig.cmake files.  This means 
that for a single project there's only one place that a user can set this flag. 
 This ensures that both the unit tests and libraries get built with the correct 
options.

2. The GTK libraries are no longer linked into a project if FB_GUI_DISABLED is 
set.  ie The resulting .so doesn't have any dependency on gtk libraries as 
verified by the ldd tool.

3. The order of include for PluginConfig.cmake has changed so that when 
cmake/common.cmake is installed, it can reference FB_GUI_DISABLED as needed to 
alter link/include paths.

Austin

Original comment by austin_p...@hotmail.com on 13 Dec 2010 at 8:03

Attachments:

• linux_gtk_link_issue.patch

[GoogleCodeExporter]

Ok, the problem here is that PluginConfig.cmake depends on common.cmake, so 
that include order won't work.

Keep in mind that PluginConfig.cmake does not apply to ScriptingCore or 
PluginCore, which are static libraries that aren't affected by project-specific 
settings.

Original comment by richarda...@gmail.com on 13 Dec 2010 at 2:26

• Changed state: Accepted

[GoogleCodeExporter]

I've had a hard time understanding all the included files and where each is 
used.  If common.cmake is included first, then it can't depend on 
FB_GUI_DISABLED as the patches currently propose to determine the value for 
GTK_XXX variables.

The two places where PluginConfig.cmake currently depends on common.cmake is in 
the example plugins.  Can the 'add_firebreath_library(log4cplus)' calls in 
PluginConfig.cmake be moved into the associated CMakeLists.txt?  This would 
then make the PluginConfig more like a configuration file where we only have 
key/value pairs and would be included first.

If you've got any pointers on how this all fits together in the build sense I 
should be able to come up with something better.  eg What is the purpose of 
splitting PluginConfig.cmake from CMakeLists.txt?

Original comment by austin_p...@hotmail.com on 13 Dec 2010 at 10:47

[GoogleCodeExporter]

I think I have this one fixed for real this time. :-P I've tried all 
combinations that I can find.

https://github.com/firebreath/FireBreath/commit/1102c89baafe534c6305048e894338cf
5555e7fc

Original comment by taxilian on 14 Jan 2011 at 1:31

• Changed state: Fixed