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 322085 - Incorrect environ prototype on darwin
Incorrect environ prototype on darwin
Status: RESOLVED INCOMPLETE
Product: gdm
Classification: Core
Component: general
2.8.x
Other Mac OS
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-21 23:41 UTC by Daniel Macks
Modified: 2006-07-12 18:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2005-11-21 23:41:47 UTC
Version details: 2.8.0.6

vicious-extensions/ve-misc.c provides compatibility functions for handling the
environment, which it accesses via an **environ array pointer, however OS X does
not supply that symbol anywhere, so linking fails with an "undefined symbol
_environ". What I need instead is:

    #include <crt_externs.h>
    #define environ (*_NSGetEnviron())

For portability, probably best to use HAVE_* tests to figure out what to do
during a given local build. In configure.in:
+/* for darwin-ish compatibility to linux **environ */
+AC_CHECK_HEADERS(crt_externs.h)
+AC_CHECK_FUNCS(_NSGetEnviron)

and then in ve-misc.c something like:

+#ifdef HAVE_CRT_EXTERNS_H
+#include <crt_externs.h>
+#endif
+#ifdef HAVE__NSGETENVIRON
+#define environ (*_NSGetEnviron())
+#else
 extern char **environ;
+#endif
Comment 1 Brian Cameron 2005-11-22 20:23:49 UTC
Fix in CVS head and 2.12 branch.  Can you test to make sure this is now
working for you?  Update the bug report with your response.  Thanks.
Comment 2 Daniel Macks 2005-11-22 21:41:12 UTC
Compiles, and 'nm' now reports "D _environ" in all the bin/ and sbin/ binaries,
so it appears fixed in ve-misc.c.

I see "U _environ" in libdwellmouselistener.so and libkeymouselistener.so, so
perhaps the gui/modules/dwellmouselistener.c and keymouselistener.c appear to
need the same NSGetEnviron fix? I don't know how to force those gtk modules to
be loaded to know for sure (are they able to see the _environ in the binary that
loads them?)...
Comment 3 Brian Cameron 2005-11-23 02:14:57 UTC
Yes, the modules should be able to access the environ structure of the program
that loads them.  To test this you can turn on accessibility in gdmsetup. 

You can also test by running various programs (like gnome-calculator).  Just set
the GTK_MODULES environment variable to the same value as defined by
GtkModulesList in gdm.conf and then run the program.  If you also set the
GDM_DEBUG_GESTURES=1 environment variable, then debug output will be sent to
syslog for you to see if it is working.  Note the AccessKeyMouseEvents and
AccessDwellMouseEvents files in gdm2/gui/modules which is where the gestures are
defined so you can tell what gestures the gesture listeners will respond to.

Note there is a bug in some Xservers that causes autorepeat detection to fail,
so you might need to set the duration to 0 for keygestures
(AccessKeyMouseEvents) for them to register.

Let me know what you find.  I'll add the same code to the gesture listeners if
it is needed.
Comment 4 Daniel Macks 2006-01-13 01:29:24 UTC
No users have reported any problems to me, so I don't think any further changes are needed at this time.
Comment 5 Brian Cameron 2006-01-13 18:33:07 UTC
Yes, but most users do not use the gesture listeners for accessibility support.  In my previous posting I asked if you could run a simple check to see if the gesture listeners work okay.  Could you run this test and let me know if we need to fix them with the "environ" change as well?
Comment 6 André Klapper 2006-07-12 18:36:05 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information Brian asked for.
Thanks!