Updated: xpm-nox-4.2.0-1

Charles Wilson cwilson@ece.gatech.edu
Tue Dec 31 07:35:00 GMT 2002


The xpm-nox has been updated to correspond to the code included in
the 4.2.0 release of XFree86.  As always, the xpm-nox package
contains the DLL, static library, and import library for the X-less
version of the Xpm library.  This release ALSO contains the X-based
DLL, cygXpm-X4.dll, so that older executables will continue to
operate correctly.  Newly compiled programs will use the "real"
libXpm.dll from the cygwin-xfree project, or the X-less cygXpm- noX4.
dll, depending on compile-time settings (see below).

CHANGES

- internal reorg to support scripted compilation
- uses auto-import so that -DXPM_STATIC and -DALL_STATIC are no
   longer needed.
- Note that you STILL need to -DXPM_NO_X if you want to use the
   xpm-nox library.

As concerns the X-less Xpm library, the header files are located in
/usr/include/noX/, and the import/static libs are now located in
/usr/lib/noX/.

This means that in order to link against the non-X-based Xpm libraries, 
you must
   a) compile using '-I/usr/include/noX'
   b) compile with the '-DXPM_NO_X' flag
   c) link using '-L/usr/lib/noX'
In some cases, for instance 'configure'-based packages, you have to
do it this way:
   CFLAGS="-I/usr/include/noX -DXPM_NO_X" LDFLAGS=-L/usr/lib/noX ./configure

For more information about the new xpm-nox package see the NOTES
section below and /usr/doc/Cygwin/xpm-nox-4.2.0.README.

--
Charles Wilson

INSTALLATION:

To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and update the xpm-nox package.

Note that we have recently stopped downloads from sources.redhat.com
(aka cygwin.com) due to bandwidth limitations.  This means that you
will  need to find a mirror which has this update.

In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.

If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

               *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com


NOTES:

o Now uses the auto-import functionality of newer binutils, and doesn'
t use __declspec(dllimport).  This means you no longer need
-DXPM_STATIC when compiling objects intended for static linking.  Just
compile as normal. HOWEVER, you need to use a special flag when
linking statically: 'gcc -static'. For dynamic linking, you need no
special link-time flags (assuming you're using binutils newer than
20010930, when --enable-auto-import was made the default).

   -- PRO: no compile time flags needed when building
           client programs; ONLY need a link-time flag
           linking to static libraries.  NO special flags
           at compile-time nor link-time when linking to
           dynamic links.
   -- CON: (partial): if using binutils older than 20010930,
           you now need a special linktime flag for dynamic
           linking (-Wl,--enable-auto-import).  However,
           with an up-to-date binutils, you don't need this.

o The following packages have been converted from old style
"-DFOO_STATIC" to the new autoimport style of DLL structure:
   ncurses readline gettext zlib libpng xpm-nox
The following have not (yet) and still need -DFOO_STATIC for
static builds:
   jpeg tiff bzip2 jbig gdbm

o can coexist with the "libXpm.dll" provided by cygwin-XFree, but
does provide additional features. The cygwin-XFree version of the Xpm
library is dynamic only; this version provides the Xpm routines
without depending on other X libraries and doesn't require an Xserver.
Also, this version can be linked statically OR dynamically.

o Comparison:  the cygwin-xfree version and the xpm-nox version:
   cygwin-xfree : + more complete         - requires Xserver
   xpm-nox      : + no Xserver needed     - a few missing routines (*)
The missing routines are the ones related to "Pixmaps" ("XpmImage"
"Buffer" " Image" and "Data" related functions are implemented).  I've
never run into a program that fails to link using the xpm-nox library
-- and it works fine with cygwin-XEmacs; however, since it isn't
fully complete:

o Based on the xpm code from the XFree86-4.2.0 distribution (xpm was
*finally* absorbed into the main XFree distro as of v4.0).  However,
there a few non- cosmetic differences between the earlier
"xpm-3.4k.tar.gz" distribution and the "xpm" directory in the
XFree86-4.2.0 sources.

o follows new naming scheme for dlls (with some complications because
of the need NOT to interfere with the cygwin-xfree version):

   - /usr/lib/noX/libXpm.dll.a  (import lib, X11-free)
   - /usr/lib/noX/libXpm-noX.a  (static lib, X11-free)
   - /usr/bin/cygXpm-noX4.dll   (dll, X11-free)
   - /usr/include/noX/xpm.h, simx.h
        (specially-hacked versions of the xpm header files)
   - cygwin-specific docs in /usr/doc/Cygwin/xpm-nox-4.2.0.README
   - generic docs in /usr/doc/xpm-nox-4.2.0/*

So ordinarily, configure-based clients will find the cygwin-xfree
versions of the header files and libraries: xpm-nox "hides" itself in
a /noX/ subdirectory to avoid conflicts.  To use the xpm-nox headers
and libraries, you must
   a) use -I/usr/include/noX when compiling
   b) define -DXPM_NO_X when compiling (or "FOR_MSW")
   c) use -L/usr/lib/noX when linking
For configure-based clients, this may require
   export CFLAGS="-I/usr/include/noX -DXPM_NO_X"
   export LDFLAGS=-L/usr/lib/noX
   ./configure

o The dll's are versioned as "4", not "3" -- but this is NOT because
the sources came from XFree86- ***4*** .0.0.  According to xpm.h, the
library version number, which remains "3.4k" even in the
XFree86-4.x.y sources, should be parsed as follows:
    XpmFormat "3"
    XpmVersion "4"
    XpmRevision "11" ( "k" is the 11th letter of the alphabet )
Quoting: "we forget the 3 which is the format number" so the SO
version is 4.11 (which I simplified down to just SOMAJOR = 4 ).

o If you are building a package that depends on xpm, and you want to
use the cygwin-xfree version, you don't need to do anything special.
Just use ./ configure as normal, or explicitly put /usr/X11R6/include
and /usr/X11R6/lib in your header/lib search paths.  No special
defines are needed; your app will be dynamically linked to the
cygwin-xfree libXpm dll.  You can't link statically; the cygwin xfree
project doesn't provide static libraries.

o Now, if you are building a package that depends on xpm, and you
wish to link to the xpm-nox version, AND you wish to link
*dynamically*, then just define -DXPM_NO_X and use -I/usr/include/noX
when compiling.  Link using 'gcc -L/usr/lib/noX'.  For more
information, see /usr/doc/Cygwin/xpm-nox-4.2.0.README.

o If you are building a package that depends on xpm, and you wish to
link to the xpm-nox version, AND you wish to link *statically*,
compile as instructed above, but link using
'gcc -static -L/usr/lib/noX'. For more information, see
/usr/doc/Cygwin/xpm-nox-4.2.0.README.

o Proactive answer to the obvious question: "Why don't you merge this
into the cygwin-XFree86 distribution?"  Answer: Not easy, and
probably not a good idea. The cygwin-XFree86 builds using standard
"xmkmf" X11-style configuration and builds.  This generates makefiles
for building the "X11 world".  Then you do "make world" and build
everything.  It's just not part of the mindset to hack up xmkmf so
that "if building on cygwin, when generating the makefiles for the
xpm target (but not the other targets), do the X thing, but also
cheat a bit over here and generate this extra library that is not
part of the X world, etc etc". It really is easier, on cygwin, to
pull xpm-nox out and build it separately.

The X11free code (not my special Makefile changes) is actually part
of the official xpm-3.4k distro, which was absorbed en mass into
XFree86.  However, the inclusion of the X11free stuff was probably an
accidental oversight on the part of the XFree86 folks, or they just
included it because there was no better place to put it so that it
doesn't get lost; now that libXpm has been absorbed by XFree86, the
"old" separate xpm-3.4 distro will probably fade into obscurity.

You're not supposed to actually *USE* the X11free code when building
X11 -- that's why the official Makefiles, even the so-called "-noX"
makefiles, don't activate the X11free code.  (Yes, it's confusing.
In the X11 world, a "-noX" makefile is a makefile that builds
X11-based code, but does not rely on a working xmkmf program; a
"-noX" makefile does NOT mean "this-makefile-builds-an-X11free-library".)
Anyway, the X11free code is *only* provided in the official xpm-3.4k
distro (and now, in the XFree86 distro) in case you (a) want libXpm
on windows, and (b) don't want X11.

Cygwin kinda straddles the fence, so libXpm straddles the fence too --
these sources and the official XFree86-xpm/xpm-3.4k sources are
synchronized aside from Makefile issues, but my version *can* build a
no-X library "out-of-box"; the cygwin-XFree86 version can't and IMO
shouldn't.

whew.



More information about the Cygwin-announce mailing list