undefined reference to __rpc_thread_destroy
Hi folks, while trying to crosscompile gtk2 (2.6.4) I've got some errors on compiling the "timescale" executable: libgthread-2.0.so: undefined reference to `__rpc_thread_destroy' libgthread-2.0.so: undefined reference to `__res' libgthread-2.0.so: undefined reference to `_h_errno' libgthread-2.0.so: undefined reference to `_errno' Does anyone have an idea what's the problem ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: undefined reference to __rpc_thread_destroy
On Sep 21, 2005, at 8:08 AM, Enrico Weigelt wrote: while trying to crosscompile gtk2 (2.6.4) I've got some errors on compiling the "timescale" executable: libgthread-2.0.so: undefined reference to `__rpc_thread_destroy' libgthread-2.0.so: undefined reference to `__res' libgthread-2.0.so: undefined reference to `_h_errno' libgthread-2.0.so: undefined reference to `_errno' Linkers prepend a _ to symbols; not all show it. Thus, _errno is likely supposed to be errno, which is a global variable from libc (specifically, errno.h); however, in a threaded libc, errno is actually preprocessor macro that looks like this #define errno (*__errno_location ()) This sounds like your linker is trying to find an actual "errno" symbol because the C compiler didn't see the proper preprocessor definition of errno at .c -> .o time. Check the includes and see if errno.h is being included. Does anyone have an idea what's the problem ? A description of the platform and toolchain would be invaluable. -- And then mama would throw the live crawdads in the boilin' water. And one day I decided I'd make my own crawdads. So I threw the crawdads in the pot, but without any water. It was just like makin' popcorn. - Ear-bending cellmate, "Raising Arizona" ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: undefined reference to __rpc_thread_destroy
* muppet <[EMAIL PROTECTED]> schrieb: > This sounds like your linker is trying to find an actual "errno" > symbol because the C compiler didn't see the proper preprocessor > definition of errno at .c -> .o time. > > Check the includes and see if errno.h is being included. hmm. the strange thing is: the symbols are exported by libc, and it seems libc is linked. (the toolchain normally works). ldd shows up that libgthread isnt linked against libpthread, but IMHO ist should be. > >Does anyone have an idea what's the problem ? > > A description of the platform and toolchain would be invaluable. hmm, it's built with crosstool. gcc-3.4.2 on gnu/linux-2.6 I could post the whole build log if that helps. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Matthias Clasen <[EMAIL PROTECTED]> schrieb: > > > Maybe just moving deprecated widgets to a separate library, like > > > libgtk2.0-compat.la, would be a better solution? We'd get well > > > maintained applications to avoid linking to this library, while at the > > > same time keeping it around for those apps that just need it and whose > > > authors are stuburn enough to not want to update. > > So let those apps depend on GTK+-2.x, like many depend on 1.2 now. > > Moving widgets to separate library will require some changes in related > > apps anyway. > > This gets proposed repeatedly, Unfortunately, it does not offer > significant benefits that would justify the costs of doing this. > Splitting GTK+ into multiple shared libraries increases the cost of > symbol resolution. It does not reduce the memory consumption You're right, as long as we're talking about splitting such silly borders as proposed. We instead should move larger/more complex widgets and dialogs to their own library, or better to their own package. For example I dont see any reason for having something like a printer dialog layout around on my system if no one really uses it. > significantly, since all the deprecated functions are unlikely to be > paged in anyway. It does complicate the build considerably. Build would become much simplier if we had a bunch of smaller libs, divided on clear and useful borders. Well, it could even easier if we had an simple and deterministic buildsystem, but that's another story ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Banginwar, Rajesh <[EMAIL PROTECTED]> schrieb: > I am really glad to see the intention of keeping the ABI same even with > 3.0 release. I'm not. Binary compatibiliy prevents us from changes in the library structures, ie. which widgets belong into which lib. Normally a new major release introduces many heavy changes - that's why its called 'major'. No one every reall expects binary compatibility, or even full source compatibilty on new major releases. They're in fact different packages with different interfaces, just doing quite the same. If you wanna have binary compatibility, just stay in the 2.x line. Or with other words: if a new release is binary compatible with 2.x, it should also be called an 2.x. > As we are going to include GTK 2.4 or 2.6 (based on distro feedback; > e.g. Redhat ships with 2.4) in the first release of desktop module of > LSB, having ABI compatibility even after platform consolidation is a > welcome decision. You probably don't want this with an 3.0 seriously. Major releases are normally *large* changes and it will take time that applications become ported to the new interface. See gtk-1.x vs. gtk-2.x There are still a lot of gtk-1.x applications out there. gtk1 vs. gtk2 are completely different packages. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Rob Adams <[EMAIL PROTECTED]> schrieb: > I don't really see much reason ever to break ABI for the forseeable > future. There's essentially nothing stopping us from simply leaving > deprecated functions in there indefinitely, other than a fairly minor Very *bad* idea. This breaks many applications sooner or later, and someone who's not involved in gtk will become really confused by that. Well, here we see the design of the first place: there is too much functionality in one library, which someday becomes obsolete, while the library at all won't. We have no clear interface borders. as Prof. Wirth already said years over years ago: "make it as simple as possible". If we had some more libraries - devided by *functionality*, then if some functionality (ie. some widget) becomes "obsolete", we simply dont maintain this lib anylonger. If these libs have their own packages, it gets even easier: there is no question about "obsolete" stuff - the packages just exist, and if someone wants to work on them, he just does. > With this in mind, we have to start asking the question of what > we think the version numbers for GTK actually mean. That's the point. AFAIK there's a wide consensous in the OSS world that jumps between major numbers break at least binary compatibility, even on source level. So on the other hand binary compatible releases should not do a major release jump. Major jumps should do something fundamentally new. We're not in the commercial world, where people rape version numbering for marketing. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Philippe De Swert <[EMAIL PROTECTED]> schrieb: > This is an issue for embedded systems using gtk (like for example GPE). > Maybe a --disable-deprecated flag could do the trick? Nice idea. BUT: it as to be absolutely clear what exactly this means. Just calling it "obsolete" is not enough. So better modelize several things considered "obsolete" as features, which can be switched by --enable-foo / --disable-foo. Of course the documentation and ./configure help should clearly state which features are obsolete. AND: before adding new features or functionality, think *really carefully* whether the new stuff *must* be in gtk and cannot reside in its own new library. > (the last thing could also be done with a deprecated macro that > warns during compilation as done in the Linux kernel) And if a certain feature is disabled, there should be macros for the disabled functions breaking the build with an appropriate error message (ie. "function foo() reqiures obsolete feature foobar, which is currently disabled"). So someone who's not an gtk developer can easily see what's happening. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Florian Boor <[EMAIL PROTECTED]> schrieb: > I'm working on the GPE project (http://gpe.handhelds.org, a software framework > for mobile devices like PDAs) which is using GTK. > Moving more features into GTK will make application development easier for us > in > a software environment of limited resources. I'm a little bit confused that you - as an embedded developer - a in favour of bloating up gtk ... > The only problem i can imagine is that GTK might become heavily bloated > and unusable on devices with limited resources. That's the major problem - not just for embedded devices. And therefore it simply shouln't be done. Separate things belong into separate libraries - evryone who needs a certain functionality is free to import the right libs for that. There's no need to put a whole operating system into one library. > So please keep in mind that there are other projects than Gnome > around using GTK which might run into trouble with the total size > and memory usage of GTK and the fact that some things might be to > heavy to belong to GTK. You're absolutely right. If gtk wants to become something like Qt, and only interesting for GNOME, just go on. Today, it's still an universal widget toolkit, not limited to GNOME, and I don't see what's bad about it. Gtk is already too fat, and the tendencies are not really good. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Stylus mode
Hi, Recently I've been doing some investigation and hacking on a stylus-mode for GTK+. A summary of my thoughts so far is in the wiki at http://live.gnome.org/GtkStylusMode, and so far there are three relevant bugs: #135666: Add style property to disable prelight #315112: Add XSetting to disable tooltips #315645: Support hold-as-right-click Disabling prelight is required as a stylus often jumps from widget to widget, so from the user's PoV the last used widget would be a different colour. Tooltips need to be disabled for the same reason: otherwise the tooltip for the last button pressed would appear for no reason, and it's impossible to show the tooltips with a stylus. Hold-as-right-click is implemented with an improved version of libgtkstyus from the GPE project, which is a GTK+ module that hooks into the event processing to handle stationary holds and turns them into right clicks. Owen has reservations with this approach so I'd appreciate as many people as possible test this. There are other features which need to be implemented: I'm currently working on drag-to-select in GtkTreeView and Tommi tells me that he had to patch the menu handling to handle a stylus properly on the 770. Basically, this mail is a heads-up to anyone interested. Any comments, suggestions, advise, and more importantly extra patches would be greatly appreciated. I'll be working on this for a while and would love to see at least portions of the work land in GTK+ HEAD. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
idea on gobject-introspection / gtk-doc metadata
One of the gobject-introspection TODOs is: - Write a scanner to create XML from annotated headers AFAIK, no one has put forward any suggestions about what those annotations would be. gtk-sharp's parser already figures out a lot of things (by assuming that the code obeys certain conventions), but there are lots of other things that can't really be guessed in most cases (like memory management conventions, or whether an int* is an out arg, an in-out arg, or an array). Meanwhile, on desktop-devel-list, there was some discussion about requiring all new APIs to be documented when they're added to the platform, and more generally about how to get hackers to be better about documenting APIs more. And then on the wiki (http://live.gnome.org/IdealDeveloperDocumentation), someone suggested: It would be great to make it easier to generate documentation for language bindings from the same sources as the C docs... For example having an annotation to indicate that a sentance/paragraph applies only to C (since it refers to C-isms like memory management issues) would make the docs easier to translate for other languages. So, what if we made it so that the extra annotations needed to generate correct gobject-introspection metadata go into the gtk-doc comments (thus encouraging people to write API docs, because it's essentially necessary to get working introspection data), and further made it so that the metadata was written in such a way that you can tell that certain parts of the documentation are directly related to certain pieces of metadata, which might therefore make them irrelevant in other language bindings. Eg: /** * gtk_tree_selection_get_selected_rows: * @selection: A #GtkTreeSelection. * @model:[[direction="out"]] A pointer to set to the #GtkTreeModel, or * %NULL. * * Creates a list of path of all selected rows. Additionally, if you are * planning on modifying the model after calling this function, you may * want to convert the returned list into a list of * #GtkTreeRowReferences. To do this, you can use * gtk_tree_row_reference_new(). * * Return value: A #GList containing a #GtkTreePath for * each selected row. [[transfer="full"] You must free each element of * the list with gtk_tree_path_free() and then free the list itself with * g_list_free().] * * Since: 2.2 **/ From this, the scanner learns that the "model" parameter is direction="out" and null-ok="1" (because the description contains "or %NULL"), and the returned GList contains GtkTreePaths and is transfer="full". The new-and-improved gtk-doc parser would ignore the "" after "#GList", and would mark the "[[transfer="full"] ...]" part in the output in some way that wouldn't affect the standard html docs at all, but could be used by another doc postprocessor to strip out that sentence, since it refers to memory-management stuff that isn't relevant to some bindings. Maybe the specific syntax here sucks, and there are still some further improvements that could be made to the idea, but I wanted to throw it out as a possibility. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
Dan Winship wrote: One of the gobject-introspection TODOs is: - Write a scanner to create XML from annotated headers AFAIK, no one has put forward any suggestions about what those annotations would be. gtk-sharp's parser already figures out a lot of things (by assuming that the code obeys certain conventions), but there are lots of other things that can't really be guessed in most cases (like memory management conventions, or whether an int* is an out arg, an in-out arg, or an array). One thing I'd like to see introspectable is versioninig information on properties & signals, right now the doc notes include "Since 2.6" on function calls and such (it would also be nice to introspect whether properties, signals & objects are depricated or not). I'm not sure if it would be better to generate the introspection metadata from the doc notes and use that in clients that use introspection data (like language bindings and GUI builders/loaders), or if it would be simpler to just build the introspection metadata into GTK+ and use that metadata to generate the docs. I'm inclined to prefer the latter, since using introspection to generate docs is already in effect, doing the opposite seems like a double standard fated to increase confusion and complexity in introspection and doc generation... But I obviously dont know enough about this gobject-introspection project... I'll have to read up on this. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
On Wed, 2005-09-21 at 12:48 -0400, Tristan Van Berkom wrote: > One thing I'd like to see introspectable is versioninig information > on properties & signals, right now the doc notes include "Since 2.6" > on function calls and such (it would also be nice to introspect > whether properties, signals & objects are depricated or not). I don't think properties and signals should be part of the introspection description at all since you can already find out everything you need by using the existing GObject / GType introspection support. Similarly, the values of GEnum and GFlags types don't need to be explicitly mentioned in the description -- all you need is the GType. -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
Torsten Schoenfeld wrote: On Wed, 2005-09-21 at 12:48 -0400, Tristan Van Berkom wrote: One thing I'd like to see introspectable is versioninig information on properties & signals, right now the doc notes include "Since 2.6" on function calls and such (it would also be nice to introspect whether properties, signals & objects are depricated or not). I don't think properties and signals should be part of the introspection description at all since you can already find out everything you need by using the existing GObject / GType introspection support. Well not exactly, my point was that you cant find out if a property or signal is depricated, and you cant find out in what stable release of GTK+ the property of signal was introduced in. But what you mean by the "introspection description" is probably something that I dont understand, I just checked out the gobject-introspection module and I still dont understand what it is. I asked this same question last week on this same list and I'll go ahead and ask it again; "whats up with this introspection enhancement plan ?" I remember the thread back in febuary called "Introspection API", I'd like to know: - Is there any kind of plan of enhancing GObject introspection ? (ofcourse including its internals such as pspecs etc). - Is it speced anywhere ? - Is there anyone working on it ? Maybe there's a web-page somewhere that will bring me up to speed on this subject ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
Tristan Van Berkom wrote: - Is there any kind of plan of enhancing GObject introspection ? (ofcourse including its internals such as pspecs etc). - Is it speced anywhere ? - Is there anyone working on it ? gobject-introspection module in GNOME CVS -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
Hi Dan, On 9/21/05, Dan Winship <[EMAIL PROTECTED]> wrote: > One of the gobject-introspection TODOs is: > > - Write a scanner to create XML from annotated headers I've started a Python script to parse GTK+ header files and generate a scheme-based definition files[1] used by PyGTK+ project. I'm working on this script to generate gobject-introspection XML file instead of scheme-based file and improving the parser to identify more elements from C source file (properties for example). > AFAIK, no one has put forward any suggestions about what those > annotations would be. gtk-sharp's parser already figures out a lot of > things (by assuming that the code obeys certain conventions), but there > are lots of other things that can't really be guessed in most cases > (like memory management conventions, or whether an int* is an out arg, > an in-out arg, or an array). Well, it's very difficult to identify this kind of element if the parsed code doesn't obey some basic conventions but I think that a XML with some basic elements is good enough to start the work. When annotations become available to all API we can start to use this data to generate XML file. Thanks, Osvaldo [1] http://bugzilla.gnome.org/show_bug.cgi?id=314959 (see attached file) -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, "http://www.pythonbrasil.com.br";) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Question around GOnce structure in Glib
Hello, We are currently in the process of standardizing GTK+ libraries in LSB-Desktop project. During the process, I ran into the GOnce structure in Glib library. I will like to understand why the member variables of this structure are declared volatile. I am trying to find out if LSB should maintain these member volatile or if it is ok not to. Thanks for the help. -Rajesh ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATH] pkg-config / $PKG_CONFIG fix
Hi folks, here's a little fix against configure to use always $PKG_CONFIG for calling pkg-config. I've got two versions, one against 2.6.4, another against 2.8.0. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - diff -ruN gtk+-2.6.4.orig/configure gtk+-2.6.4/configure --- gtk+-2.6.4.orig/configure Tue Jun 14 21:50:04 2005 +++ gtk+-2.6.4/configureTue Jun 14 21:53:15 2005 @@ -28410,7 +28410,7 @@ if test $pango_omitted_x_deps = yes ; then # Old versions of Xft didn't necessarily include -lX11 in the output -x_libs="`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS" +x_libs="`$PKG_CONFIG --libs xft` -lX11 $X_EXTRA_LIBS" fi ## Strip the .la files diff -ruN gtk+-2.6.4.orig/configure.in gtk+-2.6.4/configure.in --- gtk+-2.6.4.orig/configure.inTue Jun 14 21:50:01 2005 +++ gtk+-2.6.4/configure.in Tue Jun 14 21:57:02 2005 @@ -1075,7 +1075,7 @@ if test $pango_omitted_x_deps = yes ; then # Old versions of Xft didn't necessarily include -lX11 in the output -x_libs="`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS" +x_libs="`$PKG_CONFIG --libs xft` -lX11 $X_EXTRA_LIBS" fi ## Strip the .la files diff -ruN gtk+-2.6.4.orig/m4macros/gtk-2.0.m4 gtk+-2.6.4/m4macros/gtk-2.0.m4 --- gtk+-2.6.4.orig/m4macros/gtk-2.0.m4 Tue Jun 14 21:50:04 2005 +++ gtk+-2.6.4/m4macros/gtk-2.0.m4 Tue Jun 14 21:58:27 2005 @@ -27,7 +27,7 @@ AC_PATH_PROG(PKG_CONFIG, pkg-config, no) if test x$PKG_CONFIG != xno ; then -if pkg-config --atleast-pkgconfig-version 0.7 ; then +if $PKG_CONFIG --atleast-pkgconfig-version 0.7 ; then : else echo "*** pkg-config too old; version 0.7 or better required." diff -ruN gtk+-2.8.0.orig/configure gtk+-2.8.0/configure --- gtk+-2.8.0.orig/configure Wed Sep 21 23:17:07 2005 +++ gtk+-2.8.0/configureThu Sep 22 01:17:49 2005 @@ -27800,7 +27800,7 @@ if $PKG_CONFIG --exists x11 xext; then have_base_x_pc=true X_PACKAGES="x11 xext" -x_libs="`pkg-config --libs x11 xext`" +x_libs="`$PKG_CONFIG --libs x11 xext`" # Strip out any .la files that pkg-config might give us (this happens # with -uninstalled.pc files) diff -ruN gtk+-2.8.0.orig/configure.in gtk+-2.8.0/configure.in --- gtk+-2.8.0.orig/configure.inWed Sep 21 23:14:27 2005 +++ gtk+-2.8.0/configure.in Thu Sep 22 01:18:28 2005 @@ -1039,7 +1039,7 @@ if $PKG_CONFIG --exists x11 xext; then have_base_x_pc=true X_PACKAGES="x11 xext" -x_libs="`pkg-config --libs x11 xext`" +x_libs="`$PKG_CONFIG --libs x11 xext`" # Strip out any .la files that pkg-config might give us (this happens # with -uninstalled.pc files) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
yet another configure trouble
Hi folks, i've got yet another configure problem: It doesn't find some parts of X11 (XIproto.h), because it doesnt use the right include path. config.log shows up, that no pathes are passed to gcc for the test - this of course cannot work. How can I build gtk2 nevertheless ? Am I forced to write my own buildsystem to replace configure ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Question around GOnce structure in Glib
Banginwar, Rajesh wrote: > Hello, > > We are currently in the process of standardizing GTK+ > libraries in LSB-Desktop project. During the process, I ran into the > GOnce structure in Glib library. I will like to understand why the > member variables of this structure are declared volatile. I am trying > to find out if LSB should maintain these member volatile or if it is > ok not to. > The struct members are marked volatile because they may be concurrently accessed by other threads. One of the g_once() implementations checks one of the member variables outside of the protecting mutex (in a way that is safe, given how this code works), so you don't want the compiler to generate code that assumes the variable won't change underneath it. That said, why would an LSB standard want to document something different to the interface glib actually provides? James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
