mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-02-02 17:26:17 +01:00
remove generated files
README and INSTALL are generated files, no need to keep them under source control.
This commit is contained in:
Matthias Clasen
parent
1ce74b0dd3
commit
b160405aa0
116
INSTALL
116
INSTALL
@ -1,116 +0,0 @@
|
||||
Simple install procedure
|
||||
========================
|
||||
|
||||
% gzip -cd glib-2.20.0.tar.gz | tar xvf - # unpack the sources
|
||||
% cd glib-2.20.0 # change to the toplevel directory
|
||||
% ./configure # run the `configure' script
|
||||
% make # build GLIB
|
||||
|
||||
[ Become root if necessary ]
|
||||
% rm -rf /install-prefix/include/glib.h /install-prefix/include/gmodule.h
|
||||
% make install # install GLIB
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
GLib-2.0 requires pkg-config, which is tool for tracking the
|
||||
compilation flags needed for libraries. (For each library, a small .pc
|
||||
text file is installed in a standard location that contains the
|
||||
compilation flags needed for that library along with version number
|
||||
information.) Information about pkg-config can be found at:
|
||||
|
||||
http://www.freedesktop.org/software/pkgconfig/
|
||||
|
||||
GNU make (http://www.gnu.org/software/make) is also recommended.
|
||||
|
||||
In order to implement conversions between character sets,
|
||||
GLib requires an implementation of the standard iconv() routine.
|
||||
Most modern systems will have a suitable implementation, however
|
||||
many older systems lack an iconv() implementation. On such systems,
|
||||
you must install the libiconv library. This can be found at:
|
||||
|
||||
http://www.gnu.org/software/libiconv/
|
||||
|
||||
If your system has an iconv implementation but you want to use
|
||||
libiconv instead, you can pass the --with-libiconv option to
|
||||
configure. This forces libiconv to be used.
|
||||
|
||||
Note that if you have libiconv installed in your default include
|
||||
search path (for instance, in /usr/local/), but don't enable
|
||||
it, you will get an error while compiling GLib because the
|
||||
iconv.h that libiconv installs hides the system iconv.
|
||||
|
||||
If you are using the native iconv implementation on Solaris
|
||||
instead of libiconv, you'll need to make sure that you have
|
||||
the converters between locale encodings and UTF-8 installed.
|
||||
At a minimum you'll need the SUNWuiu8 package. You probably
|
||||
should also install the SUNWciu8, SUNWhiu8, SUNWjiu8, and
|
||||
SUNWkiu8 packages.
|
||||
|
||||
The native iconv on Compaq Tru64 doesn't contain support for
|
||||
UTF-8, so you'll need to use GNU libiconv instead. (When
|
||||
using GNU libiconv for GLib, you'll need to use GNU libiconv
|
||||
for GNU gettext as well.) This probably applies to related
|
||||
operating systems as well.
|
||||
|
||||
Finally, for message catalog handling, GLib requires an implementation
|
||||
of gettext(). If your system doesn't provide this functionality,
|
||||
you should use the libintl library from the GNU gettext package,
|
||||
available from:
|
||||
|
||||
http://www.gnu.org/software/gettext/
|
||||
|
||||
|
||||
Support for extended attributes and SELinux in GIO requires
|
||||
libattr and libselinux.
|
||||
|
||||
|
||||
The Nitty-Gritty
|
||||
================
|
||||
|
||||
Complete information about installing GLib can be found
|
||||
in the file:
|
||||
|
||||
docs/reference/glib/html/glib-building.html
|
||||
|
||||
Or online at:
|
||||
|
||||
http://developer.gnome.org/doc/API/2.0/glib/glib-building.html
|
||||
|
||||
|
||||
Installation directories
|
||||
========================
|
||||
|
||||
The location of the installed files is determined by the --prefix
|
||||
and --exec-prefix options given to configure. There are also more
|
||||
detailed flags to control individual directories. However, the
|
||||
use of these flags is not tested.
|
||||
|
||||
One particular detail to note, is that the architecture-dependent
|
||||
include file glibconfig.h is installed in:
|
||||
|
||||
$exec_prefix/lib/glib/include/
|
||||
|
||||
if you have a version in $prefix/include, this is out of date
|
||||
and should be deleted.
|
||||
|
||||
.pc files for the various libraries are installed in
|
||||
$exec_prefix/lib/pkgconfig to provide information when compiling
|
||||
other packages that depend on GLib. If you set PKG_CONFIG_PATH
|
||||
so that it points to this directory, then you can get the
|
||||
correct include flags and library flags for compiling a GLib
|
||||
application with:
|
||||
|
||||
pkg-config --cflags glib-2.0
|
||||
pkg-config --libs glib-2.0
|
||||
|
||||
|
||||
Cross-compiling GLib
|
||||
====================
|
||||
|
||||
Information about cross-compilation of GLib can be found
|
||||
in the file:
|
||||
|
||||
docs/reference/glib/html/glib-cross-compiling.html
|
||||
|
||||
Or online at:
|
||||
199
README
199
README
@ -1,199 +0,0 @@
|
||||
General Information
|
||||
===================
|
||||
|
||||
This is GLib version 2.20.0. GLib is the low-level core
|
||||
library that forms the basis for projects such as GTK+ and GNOME. It
|
||||
provides data structure handling for C, portability wrappers, and
|
||||
interfaces for such runtime functionality as an event loop, threads,
|
||||
dynamic loading, and an object system.
|
||||
|
||||
The official ftp site is:
|
||||
ftp://ftp.gtk.org/pub/glib
|
||||
|
||||
The official web site is:
|
||||
http://www.gtk.org/
|
||||
|
||||
Information about mailing lists can be found at
|
||||
http://www.gtk.org/mailinglists.html
|
||||
|
||||
To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null
|
||||
(Send mail to gtk-list-request@gnome.org with the subject "subscribe")
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
See the file 'INSTALL'
|
||||
|
||||
Notes about GLib 2.20
|
||||
=====================
|
||||
|
||||
* The functions for launching applications (e.g. g_app_info_launch() +
|
||||
friends) now passes a FUSE file:// URI if possible (requires gvfs
|
||||
with the FUSE daemon to be running and operational). With gvfs 2.26,
|
||||
FUSE file:// URIs will be mapped back to gio URIs in the GFile
|
||||
constructors. The intent of this change is to better integrate
|
||||
POSIX-only applications, see bug #528670 for the rationale. The
|
||||
only user-visible change is when an application needs to examine an
|
||||
URI passed to it (e.g. as a positional parameter). Instead of
|
||||
looking at the given URI, the application will now need to look at
|
||||
the result of g_file_get_uri() after having constructed a GFile
|
||||
object with the given URI.
|
||||
|
||||
Notes about GLib 2.18
|
||||
=====================
|
||||
|
||||
* The recommended way of using GLib has always been to only include the
|
||||
toplevel headers glib.h, glib-object.h and gio.h. GLib enforces this by
|
||||
generating an error when individual headers are directly included.
|
||||
To help with the transition, the enforcement is not turned on by
|
||||
default for GLib headers (it is turned on for GObject and GIO).
|
||||
To turn it on, define the preprocessor symbol G_DISABLE_SINGLE_INCLUDES.
|
||||
|
||||
Notes about GLib 2.16
|
||||
=====================
|
||||
|
||||
* GLib now includes GIO, which adds optional dependencies against libattr
|
||||
and libselinux for extended attribute and SELinux support. Use
|
||||
--disable-xattr and --disable-selinux to build without these.
|
||||
|
||||
Notes about GLib 2.10
|
||||
=====================
|
||||
|
||||
* The functions g_snprintf() and g_vsnprintf() have been removed from
|
||||
the gprintf.h header, since they are already declared in glib.h. This
|
||||
doesn't break documented use of gprintf.h, but people have been known
|
||||
to include gprintf.h without including glib.h.
|
||||
|
||||
* The Unicode support has been updated to Unicode 4.1. This adds several
|
||||
new members to the GUnicodeBreakType enumeration.
|
||||
|
||||
* The support for Solaris threads has been retired. Solaris has provided
|
||||
POSIX threads for long enough now to have them available on every
|
||||
Solaris platform.
|
||||
|
||||
* 'make check' has been changed to validate translations by calling
|
||||
msgfmt with the -c option. As a result, it may fail on systems with
|
||||
older gettext implementations (GNU gettext < 0.14.1, or Solaris gettext).
|
||||
'make check' will also fail on systems where the C compiler does not
|
||||
support ELF visibility attributes.
|
||||
|
||||
* The GMemChunk API has been deprecated in favour of a new 'slice
|
||||
allocator'. See the g_slice documentation for more details.
|
||||
|
||||
* A new type, GInitiallyUnowned, has been introduced, which is
|
||||
intended to serve as a common implementation of the 'floating reference'
|
||||
concept that is e.g. used by GtkObject. Note that changing the
|
||||
inheritance hierarchy of a type can cause problems for language
|
||||
bindings and other code which needs to work closely with the type
|
||||
system. Therefore, switching to GInitiallyUnowned should be done
|
||||
carefully. g_object_compat_control() has been added to GLib 2.8.5
|
||||
to help with the transition.
|
||||
|
||||
Notes about GLib 2.6.0
|
||||
======================
|
||||
|
||||
* GLib 2.6 introduces the concept of 'GLib filename encoding', which is the
|
||||
on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions
|
||||
returning or accepting pathnames have been changed to expect
|
||||
filenames in this encoding, and the common POSIX functions dealing
|
||||
with pathnames have been wrapped. These wrappers are declared in the
|
||||
header <glib/gstdio.h> which must be included explicitly; it is not
|
||||
included through <glib.h>.
|
||||
|
||||
On current (NT-based) Windows versions, where the on-disk file names
|
||||
are Unicode, these wrappers use the wide-character API in the C
|
||||
library. Thus applications can handle file names containing any
|
||||
Unicode characters through GLib's own API and its POSIX wrappers,
|
||||
not just file names restricted to characters in the system codepage.
|
||||
|
||||
To keep binary compatibility with applications compiled against
|
||||
older versions of GLib, the Windows DLL still provides entry points
|
||||
with the old semantics using the old names, and applications
|
||||
compiled against GLib 2.6 will actually use new names for the
|
||||
functions. This is transparent to the programmer.
|
||||
|
||||
When compiling against GLib 2.6, applications intended to be
|
||||
portable to Windows must take the UTF-8 file name encoding into
|
||||
consideration, and use the gstdio wrappers to access files whose
|
||||
names have been constructed from strings returned from GLib.
|
||||
|
||||
* Likewise, g_get_user_name() and g_get_real_name() have been changed
|
||||
to return UTF-8 on Windows, while keeping the old semantics for
|
||||
applications compiled against older versions of GLib.
|
||||
|
||||
* The GLib uses an '_' prefix to indicate private symbols that
|
||||
must not be used by applications. On some platforms, symbols beginning
|
||||
with prefixes such as _g will be exported from the library, on others not.
|
||||
In no case can applications use these private symbols. In addition to that,
|
||||
GLib+ 2.6 makes several symbols private which were not in any installed
|
||||
header files and were never intended to be exported.
|
||||
|
||||
* To reduce code size and improve efficiency, GLib, when compiled
|
||||
with the GNU toolchain, has separate internal and external entry
|
||||
points for exported functions. The internal names, which begin with
|
||||
IA__, may be seen when debugging a GLib program.
|
||||
|
||||
* On Windows, GLib no longer opens a console window when printing
|
||||
warning messages if stdout or stderr are invalid, as they are in
|
||||
"Windows subsystem" (GUI) applications. Simply redirect stdout or
|
||||
stderr if you need to see them.
|
||||
|
||||
* The child watch functionality tends to reveal a bug in many
|
||||
thread implementations (in particular the older LinuxThreads
|
||||
implementation on Linux) where it's not possible to call waitpid()
|
||||
for a child created in a different thread. For this reason, for
|
||||
maximum portability, you should structure your code to fork all
|
||||
child processes that you want to wait for from the main thread.
|
||||
|
||||
* A problem was recently discovered with g_signal_connect_object();
|
||||
it doesn't actually disconnect the signal handler once the object being
|
||||
connected to dies, just disables it. See the API docs for the function
|
||||
for further details and the correct workaround that will continue to
|
||||
work with future versions of GLib.
|
||||
|
||||
How to report bugs
|
||||
==================
|
||||
|
||||
Bugs should be reported to the GNOME bug tracking system.
|
||||
(http://bugzilla.gnome.org, product glib.) You will need
|
||||
to create an account for yourself.
|
||||
|
||||
In the bug report please include:
|
||||
|
||||
* Information about your system. For instance:
|
||||
|
||||
- What operating system and version
|
||||
- For Linux, what version of the C library
|
||||
|
||||
And anything else you think is relevant.
|
||||
|
||||
* How to reproduce the bug.
|
||||
|
||||
If you can reproduce it with one of the test programs that are built
|
||||
in the tests/ subdirectory, that will be most convenient. Otherwise,
|
||||
please include a short test program that exhibits the behavior.
|
||||
As a last resort, you can also provide a pointer to a larger piece
|
||||
of software that can be downloaded.
|
||||
|
||||
* If the bug was a crash, the exact text that was printed out
|
||||
when the crash occured.
|
||||
|
||||
* Further information such as stack traces may be useful, but
|
||||
is not necessary.
|
||||
|
||||
Patches
|
||||
=======
|
||||
|
||||
Patches should also be submitted to bugzilla.gnome.org. If the
|
||||
patch fixes an existing bug, add the patch as an attachment
|
||||
to that bug report.
|
||||
|
||||
Otherwise, enter a new bug report that describes the patch,
|
||||
and attach the patch to that bug report.
|
||||
|
||||
Bug reports containing patches should include the PATCH keyword
|
||||
in their keyword fields. If the patch adds to or changes the GLib
|
||||
programming interface, the API keyword should also be included.
|
||||
|
||||
Patches should be in unified diff form. (The -u option to GNU
|
||||
diff.)
|
||||
Loading…
Reference in New Issue
Block a user