g_hash_table_get_keys

[Graham Cobb-4]

The recent changes to hash tables have broken the ability to build Opensync
for the Nokia Internet tablet Maemo platform: g_hash_table_get_keys is
missing.

Until that change, it has been possible to build the trunk for the most recent
Maemo release (known as Chinook), but not earlier releases.  It is possible
to build 0.2x for all Maemo releases.

The problem is, of course, the Glib version.  Chinook ships with 2.12.12.  It
is not an option to use a newer version of Glib because Nokia (not
unreasonably) will not allow Glib to be upgraded for fear of breaking one of
the Nokia-supplied applications.

I know some projects address this by agreeing (for a period of time) a maximum
version of Glib they will use.  At least that helps people porting the
project to different platforms to know what to expect and limits the work
they need to do.

In this particular case I think it will be fairly easy to create my own
g_hash_table_get_keys using g_hash_table_foreach.  But it would be useful if
we could agree on a Glib version we are targetting.

Even if we can't agree to limit ourselves to a particular version, can I
(selfishly) encourage people to bookmark the version 2.12 reference manual
(http://library.gnome.org/devel/glib/2.12/) as their first place to look for
Glib functions?!

Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Friday 02 May 2008 12:23:16 Graham Cobb wrote:
> In this particular case I think it will be fairly easy to create my own
> g_hash_table_get_keys using g_hash_table_foreach.  But it would be useful
> if we could agree on a Glib version we are targetting.

Agreed. Do you have already a patch for this? Or should i prepare one?

>
> Even if we can't agree to limit ourselves to a particular version, can I
> (selfishly) encourage people to bookmark the version 2.12 reference manual
> (http://library.gnome.org/devel/glib/2.12/) as their first place to look
> for Glib functions?!

Ok. Fine with me - let's stay with 2.12.

Thanks for the hint!

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Friday 02 May 2008 11:34:08 Daniel Gollub wrote:
> On Friday 02 May 2008 12:23:16 Graham Cobb wrote:
> > In this particular case I think it will be fairly easy to create my own
> > g_hash_table_get_keys using g_hash_table_foreach.  But it would be useful
> > if we could agree on a Glib version we are targetting.
>
> Agreed. Do you have already a patch for this? Or should i prepare one?

Instead of implementing g_hash_table_get_keys I have created a patch which
replaces the use of get_keys with code based on hash_table_foreach.

It compiles for me but I don't know how to test it.   Is there a magic cmake
command to run the tests you have created?

The patch is attached to this message.  If you are happy you can either apply
it or I can check it in.

Graham

[opensync_hashtable.patch]

---

Index: opensync/helper/opensync_hashtable.c
===================================================================
--- opensync/helper/opensync_hashtable.c (revision 3303)
+++ opensync/helper/opensync_hashtable.c (working copy)
@@ -498,20 +498,16 @@
 
  osync_trace(TRACE_ENTRY, "%s(%p)", __func__, table);
 
- GList *e, *db_entries;
  OSyncList *deleted_entries = NULL;
 
- db_entries = g_hash_table_get_keys(table->db_entries);
+ void callback_check_deleted(gpointer key, gpointer value, gpointer user_data)
+  {
+    if (!g_hash_table_lookup(table->reported_entries, key))
+      deleted_entries = osync_list_prepend(deleted_entries, key);
+  }
 
- for (e = db_entries; e; e = e->next) {
- const char *uid = e->data;
+ g_hash_table_foreach(table->db_entries, callback_check_deleted, NULL);
 
- if (!g_hash_table_lookup(table->reported_entries, uid))
- deleted_entries = osync_list_prepend(deleted_entries, (char *) uid);
- }
-
- g_list_free(db_entries);
-
  osync_trace(TRACE_EXIT, "%s: %p", __func__, deleted_entries);
  return deleted_entries;
 }

---

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Saturday 03 May 2008 00:18:27 Graham Cobb wrote:
> Instead of implementing g_hash_table_get_keys I have created a patch which
> replaces the use of get_keys with code based on hash_table_foreach.
>
> It compiles for me but I don't know how to test it.   Is there a magic
> cmake command to run the tests you have created?

It's quite easy. Make sure you have enabled OPENSYNC_UNITTESTS and the tests
get build. I use "ccmake" for this, you can also do this
with -DOPENSYNC_UNITTESTS=ON

Once this is done just run "make test" - this will run all tests, which will
take sometime. You can also run "make Experimental" which will run the test
and later commit the test results to http://opensync.org/testing

Detailed test results/logfile should be found in the build root in
directory "Testing".

To see whats happening while running the tests you can also run make with
VERBOSE=1 - e.g.: "make VERBOSE=1 test"

I guess i have to update:
http://opensync.org/wiki/HowtoOpenSyncHacker

If you're in hurry, just go to $build/tests .. and run from this
directory ./hash

>
> The patch is attached to this message.  If you are happy you can either
> apply it or I can check it in.
I'll give it a try - feel free to commit it once you managed to run the "hash"
unti ;)

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Friday 02 May 2008 23:56:02 Daniel Gollub wrote:
> It's quite easy. Make sure you have enabled OPENSYNC_UNITTESTS and the
> tests get build. I use "ccmake" for this, you can also do this
> with -DOPENSYNC_UNITTESTS=ON

The tests won't build (let alone run!) for me:

[100%] Building C object
tests/mock-plugin/CMakeFiles/mock-sync.dir/mock_sync.o
Linking C shared module mock-sync.so
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libcheck.a(check.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libcheck.a: could not
read symbols: Bad value

There seem to be two check libraries on my /usr/lib (same as /usr/lib64 on a
debian lenny system): libcheck.a and libcheck_pic.a.  The build works if I
add the line:

SET( CHECK_LIBRARIES "-lcheck_pic" )
 
to the top level CMakeLists.txt just after the FIND_PACKAGE( Check ).

Presumably there is some way in CMake to tell FIND_PACKAGE to look for
libcheck_pic.a and only if it is not found, to look for libcheck.a.

Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Friday 02 May 2008 23:56:02 Daniel Gollub wrote:
> On Saturday 03 May 2008 00:18:27 Graham Cobb wrote:
> > The patch is attached to this message.  If you are happy you can either
> > apply it or I can check it in.
>
> I'll give it a try - feel free to commit it once you managed to run the
> "hash" unti ;)

I have run the hash unit test and the three tests all pass, so I have checked
in my change to helper/opensync_hashtable.c

Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Banck]

On Sat, May 03, 2008 at 01:21:46PM +0100, Graham Cobb wrote:

> On Friday 02 May 2008 23:56:02 Daniel Gollub wrote:
> > It's quite easy. Make sure you have enabled OPENSYNC_UNITTESTS and the
> > tests get build. I use "ccmake" for this, you can also do this
> > with -DOPENSYNC_UNITTESTS=ON
>
> The tests won't build (let alone run!) for me:
>
> [100%] Building C object
> tests/mock-plugin/CMakeFiles/mock-sync.dir/mock_sync.o
> Linking C shared module mock-sync.so
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libcheck.a(check.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when making a
> shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libcheck.a: could not
> read symbols: Bad value
>
> There seem to be two check libraries on my /usr/lib (same as /usr/lib64 on a
> debian lenny system): libcheck.a and libcheck_pic.a.  The build works if I
> add the line:
>
> SET( CHECK_LIBRARIES "-lcheck_pic" )
>  
> to the top level CMakeLists.txt just after the FIND_PACKAGE( Check ).
>
> Presumably there is some way in CMake to tell FIND_PACKAGE to look for
> libcheck_pic.a and only if it is not found, to look for libcheck.a.

Alternatively, we could just link libcheck in statically (it's just for
the test suite, it's not getting shipped AFAICT), I think this is what I
did for the Debian/Ubuntu packages; I am not sure libcheck_pic.a is
provided by all distributions anyway.


Michael

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Saturday 03 May 2008 14:54:51 Michael Banck wrote:

> > There seem to be two check libraries on my /usr/lib (same as /usr/lib64
> > on a debian lenny system): libcheck.a and libcheck_pic.a.  The build
> > works if I add the line:
> >
> > SET( CHECK_LIBRARIES "-lcheck_pic" )
> >  
> > to the top level CMakeLists.txt just after the FIND_PACKAGE( Check ).
> >
> > Presumably there is some way in CMake to tell FIND_PACKAGE to look for
> > libcheck_pic.a and only if it is not found, to look for libcheck.a.

I guess "libcheck_pic*" is Debian/Ubuntu specific?
openSUSE builds libcheck with -fPIC by default. We could also hack
FindChek.cmake module to look also for libcheck_pic

Quick look into FindCheck.cmake turned out to make use of pkg-config. But i
guess this libcheck_pic don't have a own .pc file - right?

> Alternatively, we could just link libcheck in statically (it's just for
> the test suite, it's not getting shipped AFAICT), I think this is what I
> did for the Debian/Ubuntu packages; I am not sure libcheck_pic.a is
> provided by all distributions anyway.

I would prefer to not link it statically, since there is some libcheck
debugging/development on mytodo list to support async communication from
different threads. This is way some of our tests fail randomly - e.g.: ipc,
sync, error - "check_pack.c:107: Bad message type arg". It would be easier
for me if i could continue with preloading some shared libraries instead of
doing static linking.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Saturday 03 May 2008 15:26:43 Daniel Gollub wrote:
> I guess "libcheck_pic*" is Debian/Ubuntu specific?
> openSUSE builds libcheck with -fPIC by default. We could also hack
> FindChek.cmake module to look also for libcheck_pic
>
> Quick look into FindCheck.cmake turned out to make use of pkg-config. But i
> guess this libcheck_pic don't have a own .pc file - right?

That is right.  Maybe it should be special-cased in FindCheck.cmake: do the
pkgconfig lookup but then check if the file /usr/lib/libcheck_pic.a exists
and, if so, change the value of CHECK_LIBRARIES (issuing a warning if you
like, so people know why the pkgconfig data is being ignored).

> I would prefer to not link it statically, since there is some libcheck
> debugging/development on mytodo list to support async communication from
> different threads. This is way some of our tests fail randomly - e.g.: ipc,
> sync, error - "check_pack.c:107: Bad message type arg". It would be easier
> for me if i could continue with preloading some shared libraries instead of
> doing static linking.

Could we change the default to link statically but have an option
(-DOPENSYNC_DANIEL=THATS_ME :-)) to link dynamically, which only you would
use (as it works on your system)?

Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Sunday 04 May 2008 00:51:39 Graham Cobb wrote:

> On Saturday 03 May 2008 15:26:43 Daniel Gollub wrote:
> > I guess "libcheck_pic*" is Debian/Ubuntu specific?
> > openSUSE builds libcheck with -fPIC by default. We could also hack
> > FindChek.cmake module to look also for libcheck_pic
> >
> > Quick look into FindCheck.cmake turned out to make use of pkg-config. But
> > i guess this libcheck_pic don't have a own .pc file - right?
>
> That is right.  Maybe it should be special-cased in FindCheck.cmake: do the
> pkgconfig lookup but then check if the file /usr/lib/libcheck_pic.a exists
> and, if so, change the value of CHECK_LIBRARIES (issuing a warning if you
> like, so people know why the pkgconfig data is being ignored).

Is there any reason to build check not with pic? And does it makes sense at
all to have a archive with pic? Is there in Debian/Ubuntu shared library at
all for check?

>
> > I would prefer to not link it statically, since there is some libcheck
> > debugging/development on mytodo list to support async communication from
> > different threads. This is way some of our tests fail randomly - e.g.:
> > ipc, sync, error - "check_pack.c:107: Bad message type arg". It would be
> > easier for me if i could continue with preloading some shared libraries
> > instead of doing static linking.
>
> Could we change the default to link statically but have an option
> (-DOPENSYNC_DANIEL=THATS_ME :-)) to link dynamically, which only you would
> use (as it works on your system)?

Fine with me, feel free to change this in the build environment - i can handle
both ;)

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Banck-3]

On Sun, May 04, 2008 at 02:20:49AM +0200, Daniel Gollub wrote:

> On Sunday 04 May 2008 00:51:39 Graham Cobb wrote:
> > On Saturday 03 May 2008 15:26:43 Daniel Gollub wrote:
> > > I guess "libcheck_pic*" is Debian/Ubuntu specific?
> > > openSUSE builds libcheck with -fPIC by default. We could also hack
> > > FindChek.cmake module to look also for libcheck_pic
> > >
> > > Quick look into FindCheck.cmake turned out to make use of pkg-config. But
> > > i guess this libcheck_pic don't have a own .pc file - right?
> >
> > That is right.  Maybe it should be special-cased in FindCheck.cmake: do the
> > pkgconfig lookup but then check if the file /usr/lib/libcheck_pic.a exists
> > and, if so, change the value of CHECK_LIBRARIES (issuing a warning if you
> > like, so people know why the pkgconfig data is being ignored).
>
> Is there any reason to build check not with pic? And does it makes sense at
> all to have a archive with pic? Is there in Debian/Ubuntu shared library at
> all for check?

The reason is because there is no dynamic library, Debian/Ubuntu just
ships the static libcheck.a, which is (by policy) built without -fPIC.
To cater for linking needs, an additional libcheck_pic.a is provided.  I
am not sure what the reason for no dynamic library is, probably it's
either because upstream discourages it, or the API is not stable (or
nobody requested a dynamic lib yet).

The above means that on Debian/Ubuntu, the only question is about
linking the whole test-case statically, or just libcheck.  In either
case, it will have to be relinked for a new version of check.


Michael

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel