Please report bugs via the [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database]. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to [http://mail.gnu.org/mailman/listinfo/bug-gnustep bug-gnustep@gnu.org].

User testing is vital for improving GNUstep, so please report any bugs you find!

== What to Report ==

Please include as much of this information as possible when submitting your report:
* GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
* Machine/Operating system on which you are running
* Compiler version you use
* A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
** If you have a problem configuring the libraries, please send the config.log file
** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>

The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is. If possible, the test program should be in the form of a testcase (to be built/run using the gnustep-tests script) for inclusion into the testsuites - such testcases can readily be run on MacOSX as a reference platform so that we can tell what the correct behavior is.

If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.

== Sending Fixes ==

Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (<tt>diff -u oldfile newfile > file.patch</tt>) program to do this.
For new APIs, provide header changes as well as source code changes, with macros bracketing the changes to specify which version of OSX they correspond to (see existing headers or examples) and comments in the headers documenting the behaviors of new methods etc.
For both bugfixes and new functionality, please, please, PLEASE provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code. Without testcases it's much harder to review patches, so if you don't provide testcases, your patch may simply be ignored. Testcases are executed using the gnustep-tests script from the gnustep-make package.
Add a ChangeLog entry in front of the diff file, and send the whole thing (patch plus testcases) to the bug database.

If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type <tt>M-x add-change-log-entry</tt> and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

<pre>
* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]):
Remove double_release checking. Increment released_count after
setting released array.
([NSAutoreleasePool -dealloc]): Catch release errors.
([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method.

* src/NSObject.h ([NSObject -autorelease], [NSObject -release]):
Add double_release checking.
([NSObject +enableDoubleReleaseCheck:]): New method.

* src/Foundation/NSAutoreleasePool.h: Remove
+enableDoubleReleaseCheck:, add +autoreleaseCountForObject:.

* src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:.

* src/Foundation/objc-load.h: Include objc-api file.
</pre>

== One thing at a time ==

Please try to ensure that, you only address one issue at a time (ie try to ensure that different issues are kept clearly separate, not bundled together) and address complex issues in stages, completing one stage before going on to the next.
This keeps things managable, and allows other people to understand/address the issues efficiently and quickly.

2012-01-08T05:57:11Z

Rfm: /* Who will attend FOSDEM */

Report Bugs

2011-10-02T13:33:21Z

Rfm: /* Sending Fixes */

Please report bugs via the [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database]. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to [http://mail.gnu.org/mailman/listinfo/bug-gnustep bug-gnustep@gnu.org].

User testing is vital for improving GNUstep, so please report any bugs you find!

== What to Report ==

Please include as much of this information as possible when submitting your report:
* GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
* Machine/Operating system on which you are running
* Compiler version you use
* A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
** If you have a problem configuring the libraries, please send the config.log file
** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>

The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.

If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.

== Sending Fixes ==

Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (<tt>diff -u oldfile newfile > file.patch</tt>) program to do this.
For new APIs, provide header changes as well as source code changes, with macros bracketing the changes to specify which version of OSX they correspond to (see existing headers or examples) and comments in the headers documenting the behaviors of new methods etc.
For both bugfixes and new functionality, please provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code.
Then add a ChangeLog entry in front of this and send the whole thing to the bug database.

If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type <tt>M-x add-change-log-entry</tt> and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

<pre>
* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]):
Remove double_release checking. Increment released_count after
setting released array.
([NSAutoreleasePool -dealloc]): Catch release errors.
([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method.

* src/NSObject.h ([NSObject -autorelease], [NSObject -release]):
Add double_release checking.
([NSObject +enableDoubleReleaseCheck:]): New method.

* src/Foundation/NSAutoreleasePool.h: Remove
+enableDoubleReleaseCheck:, add +autoreleaseCountForObject:.

* src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:.

* src/Foundation/objc-load.h: Include objc-api file.
</pre>

Report Bugs

2011-10-02T13:29:21Z

Rfm: /* What to Report */

Please report bugs via the [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database]. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to [http://mail.gnu.org/mailman/listinfo/bug-gnustep bug-gnustep@gnu.org].

User testing is vital for improving GNUstep, so please report any bugs you find!

== What to Report ==

Please include as much of this information as possible when submitting your report:
* GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
* Machine/Operating system on which you are running
* Compiler version you use
* A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
** If you have a problem configuring the libraries, please send the config.log file
** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>

The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.

If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.

== Sending Fixes ==

Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (<tt>diff -u oldfile newfile > file.patch</tt>) program to do this. Then add a ChangeLog entry in front of this and send the whole thing to the bug database.

If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type <tt>M-x add-change-log-entry</tt> and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

<pre>
* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]):
Remove double_release checking. Increment released_count after
setting released array.
([NSAutoreleasePool -dealloc]): Catch release errors.
([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method.

* src/NSObject.h ([NSObject -autorelease], [NSObject -release]):
Add double_release checking.
([NSObject +enableDoubleReleaseCheck:]): New method.

* src/Foundation/NSAutoreleasePool.h: Remove
+enableDoubleReleaseCheck:, add +autoreleaseCountForObject:.

* src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:.

* src/Foundation/objc-load.h: Include objc-api file.
</pre>

User FAQ

2011-10-02T13:25:20Z

Rfm:

== GNUstep General Information ==

=== What is GNUstep? ===

GNUstep is the Free Software Foundation's effort to implement Apple, Inc's (formerly NeXT Software, Inc.'s) [[Cocoa]] APIs (formerly the [[OpenStep]] Standard). Also we are building developer and user applications based on this standard which may be used to form a complete desktop experience. For more details, take a look at the [[Introduction to GNUstep|introduction]].

=== What is Cocoa? ===

Cocoa is an Application Programming Interface (API) for creating applications using the Objective-C language. It was published by Apple, Inc.(Formerly NeXT Software, Inc.).

Cocoa consists of three parts: the `Foundation Kit', a library of non-graphical objects; the `Application Kit', a library of objects useful in creating graphical applications; and the Quartz display system.

=== What platforms does GNUstep run on? ===

See the list of [[Platform compatibility|supported platforms]] for information on what machines GNUstep builds on and what the status of the ports is. Probably a few days porting to any other UNIX system where current gcc compilers and gdb debugger work.

=== Does GNUstep run on Windows? ===

The primary targets for GNUstep are free UNIX system-based platforms such as GNU/Linux and FreeBSD.

That being said, the whole environment has been ported to [http://www.mingw.org MinGW environment]
and the non-gui libraries are reported to work well.

The GUI library uses the win32 backend library to work under Windows. The backend library is a thin layer that converts the GNUstep methods to handle drawing of GUI elements to calls to the Windows API. This project is currently in beta.

=== What is GNUstep's position towards KDE and the GNOME project? ===

You can use GNUstep with GNOME and/or KDE (See [[IconManager.app]]). GNUstep displays on top of X11. You can still do programming in C (since Objective-C is just a super-set of C), and if you're using gcc 4.1 or later, you can mix C++ and Objective-C code in the same file.

GNUstep, is much more than a window manager or desktop environment. It frees you to develop cross-platform applications without the work of developing an OS independent framework from scratch. It gives you lots of basic functionality, from font panels to Unicode strings to distributed objects.

=== How can I get GNUstep? ===

Many distributions include packaged versions of GNUstep (Debian, etc.). To compile from scratch, download the GNUstep Startup package or take a look at the [[Platform compatibility]] list. Get the latest releases from [ftp://ftp.gnustep.org/pub/gnustep/core FTP].

=== How do you run GNUstep? ===

You are presumably under the misapprehension that GNUstep is some sort of program or window manager. It isn't! GNUstep is a whole load of things -- primarily a set of libraries for developing software. At present, it's those libraries, plus various command-line based support tools and service providing daemons, plus various GUI development tools, a GUI desktop/workspace application, etc. At no stage will you ever 'run' GNUstep -- you will run applications and tools and will use it's services. At some point you may well find packages distributed as 'GNUstep' systems in the way that you get 'GNU/Linux' systems packaged today. For instance, look at the [http://io.debian.net/~tar/gnustep/ GNUstep Live CD].

If you want to see a sample GUI application running you need to build GNUstep and look at the example applications in the gnustep-examples package. Build 'Finger' or 'Ink' and start it with 'openapp Finger.app' or 'openapp Ink.app'

For the best look, use WindowMaker (preferred GNUstep window manager) as your window manager. In others desktops (that have its how window manager) you can use [[IconManager.app]]

=== Is there a web site? ===

See [http://www.gnustep.org/ GNUstep Website] and [[Main_Page | GNUstep Wiki]].

=== When is GNUstep intended to be available? ===

It's usable now. Major releases are made about every six months. However, if you are a serious developer, it's probably best to use the latest snapshots.

=== What is usable? ===

Most of GNUstep is quite usable and there are many complex applications that work well. However, GNUstep does not completely track the latest changes that Apple makes to their interface and there are still some parts that need some work). This means many applications will run quite well. Applications that require very complex text handling and some unusual features and/or some of the latest additions to Cocoa may not work as well. See the Compatibility and layout section for more information.

== Compiling and Installing ==

=== How do I compile GNUstep on my machine? ===

Read the file 'GNUstep-HOWTO', which comes with the GNUstep distribution (gnustep-make), and also is available separately on the GNUstep web site. To check beforehand, take a look at the [[Platform compatibility]] list.
NB. gnustep-base-1.23.0 is the last release which supports pre gcc-4.0.0 compilers. For later releases you will want to ensure you have a more recent Objective-C compiler.

=== Are there any precompiled packages available? ===

Check the [http://www.gnustep.org/resources/sources.html Download Section] for links to RPMs, Debian packages, and BSD ports. There are also Windows installers, Mac OS X binaries and others.

=== How do I start the applications I just installed? ===

First, read http://www.gnustep.org/resources/documentation/User/GNUstep/gnustep-howto_4.html#SEC7 to make sure you have set up your environment correctly. Then from a terminal enter:

openapp Application.app

=== What are these type and size warnings? ===

These warnings:
/usr/bin/ld: warning: type and size of dynamic symbol
`__objc_class_name_NSConstantString' are not defined
are a common occurence and are due to a mismatch between the gcc compiler and the ld linker. They don't do any harm so they can be safely ignored. They have been fixed in the 3.1 version of the GCC compiler.

=== What are these import warnings? ===

Do you get this obnoxious warning whenever you compile an application, tool, or Objective-C program:
warning: using `#import' is not recommended
[...]
Up until version 3.4 of the GCC compiler, the #import directive was improperly implemented. As a result, the compiler automatically emitted a warning whenever the #import directive was used. As of gcc 3.4, this problem has been fixed, so presumably, this warning is no longer emitted when code is compiled. If you are using an earlier compiler, you can suppress these warnings by adding -Wno-import to your include (cpp) flags.

== Compatibility and Layout ==

=== Can I run NeXT OPENSTEP or Mac OS X programs on GNUstep? ===

You can't run these programs on GNUstep, but if you have the source code for the programs, you should be able to port them to GNUstep and compile them. Whether or not you will be able to run them depends on how complete GNUstep is at the time.

=== Is GNUstep following changes to OpenStep and Mac OS X? ===

Yes, gnustep-base already contains the documented changes in the Foundation library. GNUstep aims to be compatible with both the OpenStep specification and with Mac OS X. It should be easy to write an application that compiles cleanly under both GNUstep and Cocoa. GNUstep can be expected to support the OSX 10.4 version of the Cocoa APIs (we consider it a bug if it does not), but also actually supports many APIs from OSX 10.5 and later (contributions of methods from these later versions are very welcome).

=== Do we have to have the NEXTSTEP look and feel? ===

GNUstep is aiming for something like the NEXTSTEP 3.3 look and feel. Although we don't want to force anyone into this, a lot of the power and ease of use comes from this feel. The look of GNUstep is something different -- buttons and other widgets can look different but still act the same way. We hope to implement themes which will allow this.

For a different desktop feel please see [[Themability]].

=== What's up with the directory structure? ===

First of all, GNUstep uses a slightly different directory structure than NEXTSTEP or Mac OS X. Part of this is historical, part is because we can't do things the same way (see the section [[User FAQ#Why not use framework bundles?]]). Although currently the structure is very similar to the one used in Mac OS X.

It's also possible to configure GNUstep run using the standard FHS directory structured used under GNU/Linux
and other unices so that it blends better in the host environment.

=== Why not use framework bundles? ===

Framework bundles are much more difficult to port and to use, and are very unnatural on a UNIX system; extremely unnatural on Windows. In a framework bundle, the shared dynamic library is inside a framework wrapper directory. Because of this, the dynamic linker can't find it.

We have frameworks, so how do we work around that? Well, we build dynamic links from a directory inside the dynamic linker path into the framework, which work, but then you can't move the framework anywhere else on the system, otherwise you break the link, and nothing will find the framework any longer! On systems without dynamic links, like Windows, we can't even do this! We have to copy the library from the framework into the dynamic linker path, but that is simply a shared library then! Absolutely no difference. You put the dynamic library in a system directory in the dynamic linker path, and associate with that library a resource directory. OpenStep for Windows did that, and still called them frameworks. So we can do the same, and call our libraries frameworks.

Shared libraries are all in a flat directory where the dynamic linker can easily find them. This is how it works on Unixoids, Windows and probably most other systems. The OpenStep API requires us to provide some stuff for frameworks, like creating and registering a framework object automatically each time a framework is used (linked at runtime, or linked into the app), and attaching to it the list of classes inside the framework, which are not particularly trivial to implement and might make trouble when porting, as they depend on playing with the linker and the object file format. However, shared libraries are handled by the operating system for us, so we never have to use these facilities.

It's easier for Apple's Mac OS X. They can modify the system linker, compiler, the system dynamical linker as they please, because they have full control over the platform these run on. They can modify the system to support frameworks natively. GNUstep, however, is meant to run on many different platforms, platforms which we don't control (Windows, Sun Solaris, Darwin, GNU/Linux, UNIX system variants) and which have different linkers and do not support frameworks natively. On some systems it's difficult to just load a bundle or compile a shared library!

So building the core libraries as 'libraries' means that it's much easier to port them, and it's much more difficult to break them. Sure, frameworks have a bundle of resources associated with it -- but we can very easily associate a bundle of resource with a shared library, no reason why not. We are doing it. So please note that GNUstep libraries are meant to be much similar to Mac OS X frameworks. They are composed of a shared library and associated with a bundle of resources. There is a difference in terminology, in where the resources are installed, and possibly a slight difference in the NSBundle API to get to the resource bundle (anyway, it's a one line difference between Mac OS X and GNUstep, so it looks like very easy to <tt>#ifdef</tt>).

In other words, GNUstep libraries are meant to basically do the same as frameworks do on Mac OS X, but to be portable to very different platforms (such as Windows).

=== Why not use native widgets? ===

The GNUstep GUI code is divided into two libraries ... the gui proper (gnustep-gui), which handles most of the work of implementing the AppKit API, and the backend (gnustep-back) which handles the interface to the native operating system. The display server (GSDisplayServer) is one of the two classes which provide the main interface between the two parts. The other class is the graphics context (NSGraphicsContext). The later does the actual drawing whereas the former manages windows and events. This separation is just great to have multiple graphics backends like art, xlib and cairo share the same x11 display server.
So code in gnustep-gui calls methods of the display server, and code in gnustep-back translates those calls to native calls of the system you are running on.

This means that application developers use the OpenStep/GNUstep/MacOS-X AppKit API to write their applications, and the gnustep-back library uses the native functionality to do the job where possible.
For instance, you do cut and paste or DnD using the OpenStep API for that, and on an ms-windows system, the actual calls to perform the operations are the native win32 ones. ie we leave the job to the operating system, so cut and paste from gnustep applications can interact with cut and paste from native win32 applications.
Of course, where the two APIs (OpenStep and win32) operate in very different ways, the conversion between the two is hard, but often the layer between the two is quite thin.

One area where there is not much scope for overlap is drawing within a window ... the way that the OpenStep API operates is so different from ms-widnows or X-windows that high level code for drawing things inside a windows using the native operating system generally cannot fit with OpenStep, so the gui library does all the drawing inside the window with quite low level code rather than trying to map OpenStep 'controls' to native 'widgets'.

Since the basic design of the two (frontend and backend) libraries is, to draw OpenStep controls rather than try to map to native controls (because that's generally easier and makes the code very portable), we generally make no use of native widgets.
However, the gui frontend can dynamically load a theme engine to draw it's controls, and a theme engine is free to try to draw parts of a window using its own code ... so it can use the native controls where that's a practical solution.

== Troubleshooting ==

=== Problems compiling (loading shared libs) ===

If you get something like

plmerge: error while loading shared libraries:
libgnustep-base.so.1: cannot open shared object file: No such file or directory

or this:

Making all for service example...
make[2]: *** [example.service/Resources/Info-gnustep.plist] Error 1
make[1]: *** [example.all.service.variables] Error 2
make[1]: Leaving directory `/home/multix/gnustep-gui-0.8.6/Tools'
make: *** [internal-all] Error 2

This means your GNU make is being overly protective. When you try to become root (e.g. to install something), certain environment variables like LD_LIBRARY_PATH are unset in order to reduce the possibility of a security breach. If you are becoming root to install something, you need to exec the GNUstep.sh file as root, just as you do when you login. Although for simplicity, you can also try this:

make LD_LIBRARY_PATH=$LD_LIBRARY_PATH

You could also be having problems with gcc. gcc 2.96 does not work (Mandrake 8.1, perhaps others). Use a different compiler, like gcc 3.x.

=== Problems compiling (GNUstep Internal Error) ===

If you get

GNUSTEP Internal Error:
The private GNUstep function to establish the argv and environment
variables was not called.
Please report the error to bug-gnustep@gnu.org.

when compiling the gui library, there could be several things wrong. One is that you installed the gnustep-objc library, but the compiler found another Objecive-C library (like the one that came with gcc). If you are using gcc 3.x, DO NOT use the gnustep-objc library.

There could also be a mismatch between the base and gui library versions. Make sure you have the latest release of each library installed.

=== Problems with Alt key ===

It's possible the Alt key is not where you think it is or is defined incorrectly. Try running the GSTest application, KeyboardInput test (located in the examples package at [ftp://ftp.gnustep.org/pub/gnustep/core FTP]) to test it. See [http://www.gnustep.org/resources/documentation/User/Gui/KeyboardSetup.html keyboard setup] for information on how to change the settings.

If you are using WindowMaker, it's possible it is grabing this key and using it for itself. To check, open Window Maker's WPrefs and go to the Mouse Preferences. Then use another value for the "Mouse grab modifier" (bottom right). That will allow you to alt-drag things.

=== Problems with gcc3 ===

Don't forget you need to update binutils and libc also.

=== Problems with fonts ===

Why do the characters get changed to asterisks ('*')?

The problem you are getting come from the fact that the xlib backend (when not using Xft) will only use one fixed X font for a given font name. If the font "helvetica" is used inside of GNUstep the one selected X font, in your case "-*-helvetica-medium-r-normal--12-*-*-*-p-*-iso8859-1" is used. So only characters (or glyphs) that are available in that font can be displayed. The selection of which font name to use happens inside the font_cacher and is more or less at random (the order fonts are listed by the X system).

You can influence the fonts that are available by setting:

defaults write NSGlobalDomain GSFontMask "*iso8859-13"
font_cacher

(or using a different character set, like iso8859-2). This is really a bug in GNUstep, but it hasn't been fixed yet.

The other option is the use the art backend, which handles fonts much better. When compiling gnustep-back, start with

./configure --enable-graphics=art

=== No characters displayed ===

When using the xlib backend, no characters are displayed in any GNUstep applications.

The xlib backend has font anti-aliasing turned on by default. It's possible that GNUstep can't find any fonts on your system that can be properly anti- aliased. Try

defaults write NSGlobalDomain GSFontAntiAlias NO

to turn off font anti-aliasing.

=== No Makefile ===

I tried to compile something and I get:

GNUmakefile:27: /Makefiles/common.make: No such file or directory
GNUmakefile:39: /Makefiles/aggregate.make: No such file or directory
gmake: *** No rule to make target `/Makefiles/aggregate.make'. Stop.

Make sure you have installed the gnustep-make package and also type something like

source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

depending on your GNUstep's installation path.

You can put this line in your `.profile' or `.bash_profile' file so that it is done automatically when you log in.

== Misc ==

=== Why don't you just have Gorm output Renaissance files? ===

Philosophical and architectural incompatibilities.

=== Is there a way to install GNUstep on Mac OS X? ===

Yes! Please see [[Platform:BSD#Mac_OS_X | MacOS X installation notes]].

=== Is there any way to use gnustep-make and gnustep-base without using openapp/opentool? ===

opentool is obsolete and you should be able to run command-line programs directly from your
shell prompt like any other command-line program.

openapp is useful to run applications but in standard situations you can also run directly
the program from within the .app folder.

=== Can GNUstep help with porting applications from MacOS-X? Is there any HOWTO on that? ===

See for example Tamsys.

=== How difficult it should be to port it to Linux and GNUstep? ===

Somehow relevant may be discussion on How to port to GNUstep Answered. Unfortunately this link is broken now. Dredge around in the google discussion group, I guess. I couldn't find anything helpful.

=== Can I deploy my GNUstep application without requiring people to install GNUstep? ===

No. Compare it to running Java applications without people requiring to install Java runtime environment.

=== How can I get more information on Objective-C ? ===

Take a look at the [[Objective-C]] page.

[[Category:FAQ]]

WebServices

2010-06-15T08:34:16Z

Rfm:

{{stub}}

{{Framework|
shortdescription = Framework for a GNUstep program to interact with web services |

currentversion = [ftp://ftp.gnustep.org/pub/gnustep/libs/WebServices-0.4.0.tar.gz 0.4.0] |

releasedate = Jun 14, 2010 |

license = LGPL |

overview =

The WebServer library contains a collection of classes to be used for creating client and server 'web service' applications. it is also useful for general XML work as the API that that is particularly simple and efficient.

The GWSService class is used to make RPCs as a client. This class makes use of GWSCoder classes to serialize the request before sending it to the remote system, and to deserialize the response received.

Different GWSCoder sublasses handle different encoding mechanisms, and this library provides one for XMLRPC (because it's a nice, simple mechanism good for most normal applicatiions), and one for SOAP (because, while it's a horrible, bloated, designed-by-comittee mechanism, it's also the most common one by far and the standard one for web services).

The GWSCoder base class provides support for decoding an XML document to a tree of GWSElement objects, and encoding a tree of GWSElement objects to form an XML document.

The GWSElement class represents an element in an XML document and provides a concise set of methods for locating and manipulating the elements within a tree representing the entire document.

The remaining classes in the library provide support for WSDL, allowing a WSDL document to be parsed, and SOAP calls to be made to a service described in the WSDL, with binding information from the WSDL used to build the calls from a minimal set of parameters.
|

features =
* Easy/simple ObjectiveC API for parsing/generating XML documents, XMLRPC and SOAP remote procedure call support, WSDL support, GNUstep and OSX|

maintainer = Richard Frith-Macdonald |

relatedlinks = |

category = [[Category:Networking Frameworks]]
}}

Objective-C Compiler and Runtime FAQ

2010-06-11T09:46:34Z

Rfm: /* Can I use Apple's Runtime APIs? */

== Objective-C Compiler and Runtime FAQ ==

An Objective-C implementation comes in two components; a compiler and a runtime library. The compiler is responsible for parsing the source code and produces a binary that contains calls to the functions in the runtime library. This library is responsible for things like message sending and introspection.

=== How Many Runtimes Are there? ===
----------------------------

If you have used Objective-C on Mac OS X, then you will have used one or both of Apple's two Objective-C runtimes. The Apple legacy runtime is based on the version implemented by NeXT back in the '80s, although it has seen some improvements since that time and is often referred to as the NeXT runtime. Apple's modern runtime is a complete rewrite, introduced with OS X 10.5. The modern runtime is required for Objective-C 2 and is the default on 64-bit platforms.

The implementation of Objective-C produced by NeXT was based on GCC and as such NeXT was required to release the relevant compiler changes. The NeXT Objective-C runtime was not open sourced (it was later, after Apple bought NeXT, but the code is not particularly portable and so is not used on platforms other than Darwin) and so the GNU project created a new one, generally referred to as the GNU runtime.

In 2009, a fork of this was committed to GNUstep subversion repository as libobjc2. This contains a lot of new features and removes a lot of legacy code, but is not yet considered production ready. Unlike the original GNU runtime (which will be referred to as the GCC runtime, for differentiation), this can be built outside of the GCC tree and distributed independently. The GNUstep runtime supports two ABIs. One is compatible with the GCC runtime, the other is new and is designed to support Objective-C 2.

=== Which Runtime Should I use? ===
---------------------------

If you are using a recent version of GCC to compile your code then you should have a copy of the Objective-C runtime library that came with your compiler.

If you are using a very old version of GCC then you may need to use a newer version of GNU runtime. If you experience problems with the version of runtime that came with your compiler, then you should install libobjc from GNUstep subversion (libs/libobjc/trunk). This is a copy of version 1.6 of the GCC runtime which is modified to build outside the GCC tree.

For more advanced features, currently only supported if you compile with Clang, you will need the GNUstep runtime. This is not currently considered production ready. It should work as a drop-in replacement for the GCC runtime, but some of the advanced features are not well-tested.

=== What is or was the Étoilé Runtime? ===
----------------------------------

The Étoilé Runtime is a research prototype that was originally intended to succeed the GNU runtime. After some time, it was determined that porting GNUstep to a completely new - and radically differently designed - runtime would be a massive undertaking, as would providing all of the related compiler support. It was also decided that two incompatible ABIs would not benefit anyone. The author of the Étoilé runtime is the maintainer of the GNUstep runtime and has back-ported most of the improvements from the Étoilé runtime to the GNUstep runtime.

=== Which Compiler Should I Use? ===
----------------------------

The history of Objective-C in GCC is somewhat complicated. Originally, NeXT was forced to release the original Objective-C front end in order to comply with the GPL. This code was not quite compatible with the GNU runtime and so it was modified. NeXT did not adopt these modifications and so each release of GCC by NeXT, and then Apple, contained changes that needed back-porting to the main branch of GCC.

For a long time, GCC was the only compiler that worked with GNUstep. Unfortunately, the GCC team has not invested much effort in Objective-C in the last few years and it currently lags behind Apple's version by a significant amount.

As of version 4.3, the Free Software Foundation changed the license of GCC to version 3 of the GNU General Public License. This means that future versions will not be shipped by Apple. OS X 10.6 ships with three compilers:

* Apple's fork of GCC 4.2.1
* LLVM-GCC
* Clang

The latter two use the Low-Level Virtual Machine (LLVM) for code generation. This is a BSD-licensed compiler infrastructure used by several other projects. LLVM-GCC is a hybrid, using Apple's version of GCC for parsing and LLVM for optimisation and native code generation. Clang is a new front end for LLVM.

Currently, LLVM-GCC is based on Apple's GCC and so does not support the GNU runtime. There is an effort underway to rewrite LLVM-GCC as a plug in for GCC 4.5, at which point it should support as much Objective-C as GCC currently does.

Unlike GCC, Clang features a clean abstraction layer between the runtime-specific and runtime-agnostic parts of the compiler. This means that adding support for new features on the GNU runtime is simply a matter of implementing the relevant methods in the CGObjCGNU class. This means that Clang is able to support almost everything on the GNUstep runtime that it does on either of the Apple runtimes. Note, however, that Clang only recently reached version 1.0 status. Current subversion builds are more stable, but things like generating debugging info are still somewhat unreliable.

=== Which Bits of Objective-C 2 Work? ===
---------------------------------

The answer to this question depends on the combination of compiler and runtime library that you are using. Currently, no features of Objective-C 2 work with GCC.

If you compile with Clang then you have access to declared properties, fast enumeration, and blocks. Note that both of these require some support from the runtime. This must be provided either by the GNUstep runtime or by the ObjectiveC2 framework, which you can acquire from Étoilé subversion. For blocks to work, you must also compile with -fblocks.

If you compile with the -fobjc-nonfragile-abi flag then you will use the new ABI. This is only supported with the GNUstep runtime. This adds:

* Property introspection
* Introspection on optional protocol methods
* Non-fragile instance variables
* Forwarding proxy support

Unlike Apple's non-fragile ABI, it is possible to mix code compiled for our fragile and non-fragile ABIs with some caveats. Message sending from code compiled with the fragile ABI will not be able to take advantage of forwarding proxies. If you subclass a non-fragile ABI class with a class compiled with the fragile ABI then you will not receive any benefits; the class compiled with the fragile ABI must be able to see all of the instance variables in the superclass at compile time or things will break. Some benefits will be obtained the other way around, however. A class compiled for the fragile ABI will always be able to access its own instance variables safely when the superclass changes, even if the superclass layout changes. It will, however, only be able to safely access instance variables declared in superclasses safely if the superclass is also compiled with the non-fragile ABI or if the superclass instance variable layout does not change.

=== Can I use Apple's Runtime APIs? ===
-------------------------------

You not only can, but should!

With OS X 10.5, Apple introduced a new set of APIs for interacting with the runtime. These hid the implementation details - previously all public - behind a set of public functions, implemented on both the modern and legacy runtimes.

These functions are supported by the GNUstep runtime and can also be used with the GCC runtime if you link against Étoilé's ObjectiveC2 framework.

From release 1.20.0 of the base library onwards the new runtime APIs are built in to the GNUstep base library (the Étoilé ObjectiveC2 framework is incorporated into base and extended/improved) so that the new APIs can be used with both old and new runtimes.

=== What About Garbage Collection? ===
------------------------------

GNUstep has supported garbage collection via the Boehm GC for some years. Efforts are underway to bring this to closer compatibility with Apple's new implementation.