After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347360 - gnome-vfsmm-2.14.0 does not compile under GNOME-2.15.4
gnome-vfsmm-2.14.0 does not compile under GNOME-2.15.4
Status: RESOLVED FIXED
Product: gnome-vfsmm
Classification: Deprecated
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2006-07-13 01:00 UTC by Joseph Sacco
Modified: 2011-01-16 23:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
patch to handle bonobo dependencies (1.40 KB, patch)
2006-07-13 13:18 UTC, Joseph Sacco
none Details | Review

Description Joseph Sacco 2006-07-13 01:00:12 UTC
gnome-vfsmm-2.14.0 does not compile under GNOME-2.15.4:


g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"libgnomevfsmm\"  -I../../libgnomevfs -I../../libgnomevfs -pthread -DORBIT2=1 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/glibmm-2.4 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/lib/glibmm-2.4/include -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/sigc++-2.0 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/lib/sigc++-2.0/include -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/glib-2.0 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/lib/glib-2.0/include -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/gnome-vfs-2.0 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/lib/gnome-vfs-2.0/include -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/gconf/2 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/orbit-2.0 -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include/gnome-vfs-module-2.0  -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include  -g -I/usr/local/src/GARNOME/2.15/garnome-2.15.x/include -L/usr/local/src/GARNOME/2.15/garnome-2.15.x/lib -O2 -pipe -MT transfer.lo -MD -MP -MF ".deps/transfer.Tpo" -c -o transfer.lo transfer.cc; \
then mv -f ".deps/transfer.Tpo" ".deps/transfer.Plo"; else rm -f ".deps/transfer.Tpo"; exit 1; fi
../../libgnomevfs/libgnomevfsmm/mime-handlers.h:75: error: expected constructor, destructor, or type conversion before '*' token
make[5]: *** [mime-handlers.lo] Error 1


-Joseph
Comment 1 Joseph Sacco 2006-07-13 01:46:11 UTC
I have been poking at this problem, comparing with gnome-vfsmm-2.14.0 built under GARNOME-2.14.x. 

One thing that I notice with the 2.15.4 build is there are problems with files in libgnomevfs/libgnomevfsmm/.deps. Four of the .Plo files, 

   * async.Plo
   * dns-sd.Plo
   * mime-handlers.Plo
   * utils.Plo

contain only the line "# dummy"

None of the .Plo files in the 2.15.4 build of gnome-vfsmm-2.14.0 contains 

    Bonobo_Activation_types.h

which is why tranfer.cc does not compile.

Now the question is "what happened to the .deps files?"  I suspect that it has something to do with the upgrade of libbonobo to version 2.15.0.

Will poke futher.


-Joseph


Comment 2 Joseph Sacco 2006-07-13 02:15:52 UTC
I found the source of the problem. gnome-vfs-2.0.pc [gnome-vfs-2.15.3] no longer requires bonobo-activation-2.0. Consequently, LIBGNOMEVFSMM_CFLAGS never picked up any bonobo include files.

Hmmm... What to do?  I can certainly hack the gnome-vfsmm configure file.

Thoughts???


-Joseph
Comment 3 Joseph Sacco 2006-07-13 02:44:42 UTC
I should read d-d-l more carefully...

   http://mail.gnome.org/archives/desktop-devel-list/2006-July/msg00032.html


-Joseph
Comment 4 Murray Cumming 2006-07-13 06:15:17 UTC
This is very odd.

If gnome-vfs no longer depends on bonobo then I guess we need to look at making gnome-vfsmm no longer depend on bonobo, being very careful about API/ABI changes.

Presumably (I'm not at my PC), this line uses something from Bonobo:

../../libgnomevfs/libgnomevfsmm/mime-handlers.h:75: error: expected
constructor, destructor, or type conversion before '*' token
Comment 5 Joseph Sacco 2006-07-13 13:18:19 UTC
Created attachment 68864 [details] [review]
patch to handle bonobo dependencies

Murray,

Here is a patch to handle the bonobo-dependency changes in gnome-vfs-2.15.x. The patch allows gnome-vfsmm-2.14.0 to build within the GNOME-2.15.4 environment.  The patch clearly needs some work [version - #ifdef stuff] if it is to work properly with GNOME-2.14.x

-Joseph
Comment 6 Murray Cumming 2006-07-13 13:22:02 UTC
Thanks. That's a good short-term fix for the build. Anyone should free to apply it, with a ChangeLog entry.

But I guess in the longer term we should remove the API that uses Bonobo, following the same tortured this-doesn't-really-break-ABI logic that gnome-vfs has used. My bad feelings about this are however slightly soothed by the good feeling I have at the idea of not depending on Bonobo.

Comment 7 Joseph Sacco 2006-07-13 14:02:40 UTC
OK... 

BTW, the examples run.  

My only concern at this point is whether or not the .pc files should contain bonobo stuff since gnome-vfs-2.15.3 will no longer pull it in when gnome-vfs-2.0 is cited as 'Required'.

-Joseph
Comment 8 Murray Cumming 2006-07-13 14:29:09 UTC
No, I'd prefer not to change the .pc files.
Comment 9 Joseph Sacco 2006-07-13 14:40:18 UTC
you are correct.  I thought about it some more.

So... the patch is "workable" for now.

-Joseph
Comment 10 Murray Cumming 2006-07-13 17:25:25 UTC
Should be "fixed" in gnome-vfsmm 2.15.1, just released:

2006-07-13  Murray Cumming  <murrayc@murrayc.com>

        * libgnomevfs/libgnomevfsmm/mime-handlers.cc:
        * libgnomevfs/libgnomevfsmm/mime-handlers.h: Removed
        get_default_component(), get_short_list_components(),
        get_all_components(), id_in_component_list(), and
        id_list_from_component_list() because the underlying
        functions have been removed from gnome-vfs. This _is_
        an ABI break, but we are taking this extraordinary step
        because it is very unlikely that anyone is using these
        methods, and in order to remove the dependency on Bonobo.
        get_default_component() was actually never implemented
        so it cannot have been used.
        If you really need to use these methods, you should use
        the underlying C functions, which have been moved to
        libbonobo.