Contents Up Previous Next

UNIX

Is there a GNU configure script for wxWindows?
Linux issues
Solaris 2.x issues
Compiling on OSF/1
Compiling on HP kit
Compiling Sun dynamic libraries
I get a link error under SunOS: the symbol XtShellStrings is resolved.
I get a libXmu link or run-time error.
How do I link applications statically with X and Motif libraries?
What to do if GCC gives non-wxWindows link errors
Why does the XView or Motif file selector crash?
Under AIX, wxTheApp does not initialize properly and causes a wxWindows error message.
When deleting a frame or dialog box, the program crashes.
How can I compile PROLOGIO successfully under UNIX?
How can I compile wxXPM successfully under UNIX?
I get libXmu.so.4 (or similar) not found on linking.
Why do I have compilation problems compiling wb_list.cpp on Solaris?
Why do I get an undefined virtual table error?
Unresolved references using Linux and SWiM Motif 2.0
Duplicate symbol error when compiling with xlC on AIX 4.1.4


Is there a GNU configure script for wxWindows?

Yes, it's in the contrib/wxshlib directory of the distribution, from 1.66 onwards.


Linux issues


Segmentation fault on startup

Some versions of gcc are buggy and cause problems with wxWindows and other software.

From Wolfram Gloger:

I'm afraid the answer is probably `don't use Slackware' (for C++
development, that is, it may well be a great distribution otherwise).
Slackware has been well known for shipping inconsistent
compiler/library versions.  At this stage, you should really only use
gcc-2.7.2 with libg++-2.7.1.4 (note the trailing `.4' indicating
H.J.'s patchlevel).

A good test would be to compile `#include <stream.h> int main() { cout
<< "Hello\n"; }' and see if that runs.  If it doesn't, you have
obviously no chance to run wxWindows, either.

Regards,
Wolfram.
The experience of another Linux user:

Hi Julian,

you wrote:
>This is quite a common experience under Linux and it is solvable - I must 
>try to get a coherent story on what the problem and fix is.

you are right, it's very difficult to get a coherent story on what it depends.
After getting some experience I can definitively say:

1) 	At first it is a problem of libg++-2.7.0 -> libg++-2.7.1.3
	Don't use them, they will not work.  SEG-FAULT !!
	You have to use libg++-2.7.1.4 . FOUR !! is very importent, 
	thanks Wolfram.

2)	It is a problem of gcc/g++ 2.7.0 too, exspecially of the linker.
	Maybe it's only the libc.a . I have changed only whole packages.
	It caused a problem with the slider.

3)	libiostream.a came with libgxx-2.7.0 .
	In the package libgxx-2.7.1.4 wasn't any libiostream.
	{{So I couldn't upgrade this library. 
	  I still have problems, now the choise-box causes failure
	  Wolframs little program 'cout' starts with SEG-FAULT.}}
	  I just heard it's now itegrated in the new stdc++ and I
	  have to delete the old one.

Unfortunately there is no revisions-number and patchlevel-number in the
library-name of libg, ldso-1 and libiostream and I don't know how to get it.

Point 1) + 2) will help other Linux user if they could find it your 
NOTES FOR LINUX USER.

That's all till now.
Thanks a lot for your help and to all the other helpfull people. 
Otherwise I didn't search for a solution at this point.

Regards,
Juergen

I get a link error for strchr

Try adding -lstdc++ to the link flags.


Why do the makefiles not work?

You may be using 'pmake': the wxWindows makefiles require you to be using the default GNU make, which has a slightly different syntax (for example, the include statement syntax is different).


My binaries are enormous! What can I do?

wxWindows 1.60 improves on 1.50 by the use of GCC pragmas to specify which files are interfaces and which are implementation.

Also, if you compile everything without debugging information, GCC will use dynamic link libraries for X11, XView and some others; this reduces the size of the binary substantially.

You can also create a shared version of the wxWindows library; see contrib/wxshlib for GNU autoconf files for building shared and static libraries, and also Building shared libraries.


Building shared libraries on UNIX

See contrib/wxshlib for GNU autoconf files for building a shared version of wxWindows. Here's another way to do it in Linux:

Date: Mon, 10 Feb 1997 21:42:29 +0100
From: Erwin Nijmeijer <E.Nijmeijer@inter.NL.net>
Reply-To: E.Nijmeijer@inter.NL.net
To: julian.smart@ukonline.co.uk
Subject: Shared library & gcc & IOU1

After looking at your homepage I discovered that there is a special
script for creating a shared wxWindows library. To create a shared
version of the library, I used a much easier way :

a) Add -fPIC to CPPFLAGS
b) create the static library as described in the documentation
c) copy the library to a special temporary directory and extract all
   the objects using the archiver :
   ar x libwx_motif.a

d) rebuild the shared library using these objects :
   gcc -shared -o libwx_motif.so *.o

maybe I'm thinking just too simple but it seems to work fine with me !


How can I reduce wxWindows compilation times on Linux?

A solution from Giovanni Agostino Andrea Giorgi (giorg@dsi.unimi.it).

For Linux Users with at least 8Mb of Ram.....
About wxWin 1.63 compilation Speed. 
I have found a small solution  for this  problem:

Rules are simple....:)

	1) DO NOT run  X-Windows BEFORE compiling
	2) Include DIRECTLY the ".h" files
	3) Options for gcc:
		-O0 [ -w ]
	4) Try to use more files, to link togther at the end...
With this method I reduced compilation time (and linking, of 
course !) of minimal.cpp from over 4' to  about 1':30''.

I think this is good, because I have only 8 Mb....

Thank to all !
Regards

Why does the Xfree ATI Mach32 server hang when drawing graphics?

(This FAQ is probably obsolete by now).

Harri Pasanen has discovered a bug in the Mach32 server. It hangs if using pens with wxDOT linestyle, and width zero.

This has been reported to the Xfree developers.


Solaris 2.x issues


I get some warnings and link errors. What gives?

You need to:

Note that the libgen.a lives in /usr/ccs/lib, if you have installed the programming tools option.

Version 4.0 of Sun C++ is apparently more pedantic than older versions, and requires the use of CC -migration to help with the necessary changes. You may need to include the file strings.h where the file string.h is included, with CC, e.g. in wb_utils.cpp.

Someone reported that link errors on a SPARCStation were cured by adding -lucb and -I/usr/ucbinclude/sys.

For dynamic linking under Solaris 2.3, the following changes are required:

Here are my (JACS) own experiences. As of 25th May 1995, I finally got a clean compilation under Solaris (using XView), though I needed to change a lot of files, e.g. in wxXPM and wxImage. The following is a script I wrote to save editing make.env, for Solaris compilation. It shows the kinds of settings required.

I think for some environments you may need to add -L/usr/ccs/lib -lgen to the COMPLIBS line.

The changes required to compile under Solaris will be in version 1.62 beta (b). New versions of Solaris and the SunPro compiler may break all this, of course.

#!/bin/sh
# makeunix
# Invokes makefile with specific XLIB and XINCLUDE settings,
# IFF your version of make can take the -e flag
# (environment variables take precedence.)
export XINCLUDE
export XLIB
export CC
export CCC
export CCLEX
export DEBUG
export WARN
export RANLIB
export COMPLIBS
export OPTIONS
CC=CC
CCC=cc
CCLEX=cc
OPTIONS=-DSVR4
COMPLIBS='-ldl -lsocket -lnsl'
XINCLUDE=-I/usr/openwin/include
XLIB='-L/usr/local/X11/lib -L/usr/openwin/lib'
DEBUG=
WARN=
RANLIB=echo
make -f makefile.unx -e $@

Compiling on OSF/1

Here's how.

From: Asociacion Fisica Universidad <afu2@eucmos.sim.ucm.es>
Subject: Ported wxWin 1.60 to OSF1
To: J.Smart@ed.ac.uk

        Hi!

        I've been playing around with wxWin (great package!) and I've 
make it to compile under OSF/1 with motif. I send you the modified 
make.env, just in case.

        There is a minor change in a file I can't remember which is, but 
is in someplace in which it makes a wait and you say it's bad, that it 
has to be remade. There's a conditional compilation there, and where we 
can fidn #if !defined(SVR4) && .. etc, just include a !defined(OSF1). It 
shoudl work all right.

        Well, here's the make.env.osf1. If you have any comments, let me know!

# make.env

# slightly touched by Iniaky Perez Gonzalez (afu2@fis.ucm.es, 2:341/5.31) 
# to work fine under OSF/1

# Common makefile settings for wxWindows programs
# This file is included by all the other makefiles, thus changes 
# made here take effect everywhere (except where overriden).
#
# An alternative to editing this file is to create a shell script
# to export specific variables, and call make with the -e switch
# to override makefile variables. See wx/install/install.txt.
# And you can override specific variables on the make command line, e.g.
#
# make -f makefile.unix DEBUG=''
#

########################## Compiler ##################################

# C++ compiler
#CC = gcc-2.1
CC = cxx

# C compiler for pure C programs
# Typical: CC=g++ , CCC=gcc
#          CC=cl386 /Tp, CCC=cl386
#
# (Used only for XView, file sb_scrol.c)
#
CCC = cc

# Compiler used for LEX generated C
CCLEX=$(CCC)

########################## Compiler flags #############################

# Miscellaneous compiler options
# May need to add -D_HPUX_SOURCE_ for HPUX
# Solaris: add -DSVR4
OPTIONS= -Dosf1 -DOSF1 -D__OSF1

# Debugging information
#DEBUG = -g
DEBUG =

# Warnings
WARN = 

# Which GUI, -Dwx_xview or -Dwx_motif (don't change this)
GUI = -Dwx_motif

# Optimisation
# OPT = -O
OPT =

# Options for ar archiver
# AROPTIONS = crs # For IRIX. Also, comment out ranlib line.
AROPTIONS = sruv

# Compiler libraries: defaults to GCC libraries
# Sun with Sun CC: -lc
# Solaris: -lgen -ldl -lsocket -lnsl
#   and/or possibly -lucb, whatever that is...
# SGI:     -lPW
COMPLIBS=-lc -lm -lcxx

# Compiler or system-specific include paths
# E.g. some SPARCStations need
# -I/usr/ucbinclude/sys
COMPPATHS=-I/usr/include/cxx

# HP-specific compiler library: an AIAI convenience
HPCOMPLIBS=

# LDLIBS for specific GUIs
MOTIFLDLIBS = -lwx_motif -lXm -lXt -lX11 -lm $(COMPLIBS)
XVIEWLDLIBS = -lwx_ol -lxview -lolgx -lX11 -lm $(COMPLIBS)
HPLDLIBS=-lwx_hp -lXm -lXt -lX11 -lm

# Default LDLIBS for XView (don't change this)
LDLIBS = $(XVIEWLDLIBS) -lbsd

# _ol or _motif (don't need to change, the makefiles will take
# care of it if you use motif/hp/xview targets)
GUISUFFIX=_motif

########################## Directories ###############################

# Replace X include/lib directories with your own
INCLUDE=-I/usr/include -I/usr/include/X11 -I/usr/include/Xm
LIB=-L/usr/local/X11/lib -L/usr/lib/Xm
#XINCLUDE=-I/aiai/packages/motif1.2.1/motif/include -I/aiai/packages/X.V11R5/inc
lude
#XLIB=-L/aiai/packages/motif1.2.1/motif/sun4/lib -L/aiai/packages/X.V11R5/lib

# A convenience, for HP compilation
HPXINCLUDE=-I/usr/include/Motif1.2 -I/usr/include/X11R5
HPXLIB=-L/usr/lib/Motif1.2 -L/usr/lib/X11R5

# Shouldn't need to change these...
WXINC = $(WXDIR)/include/x
WXBASEINC = $(WXDIR)/include/base
WXLIB = $(WXDIR)/lib/libwx$(GUISUFFIX).a
INC = -I$(WXBASEINC) -I$(WXINC) $(COMPPATHS)

# Directory for object files (don't change)
OBJDIR = objects$(GUISUFFIX)

# You shouldn't need to change these...
CPPFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUG) $(WARN) $(OPT)
CFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUG) $(WARN) $(OPT)
LDFLAGS =  $(XLIB) -L$(WXDIR)/lib

# Extra patch link for XView
XVIEW_LINK = $(WXDIR)/src/x/objects_ol/sb_scrol.o
Also:

Hi,

just one word on how to compile Wx166b on DEC/OSF

The DEC cxx compiler does'nt understand the new .cpp extensions as C plus plus
source files.

Solution
---------

modify the make.env file to add -x cxx to the compiler options

->   OPTIONS = -Dosf1 -DOSF1 -D__OSF1 -x cxx

the -x cxx argument forces to compile any source to C plus plus

(see the FAQ for a complete list of other changes to introduce in the
make.env file)
Facultes Universitaires Catholiques de Mons (F.U.Ca.M.)
Bart JOURQUIN
Departement "Informatique et Gestion Quantitative"
Groupe "Transport et Mobilite"
Chaussee de Binche, 151a
7000 Mons (Belgique)
Tel: (32) 65 32.32.93
Fax: (32) 65 31.56.91
E-mail: jourquin@message.fucam.ac.be

Compiling on HP kit

Here's how.

Date: Fri, 21 Apr 1995 09:03:32 -0600
From: Bruce Lee <lee@abraham.et.byu.edu>
Apparently-To: J.Smart@ed.ac.uk
Status: REO

Julian,

Thank you for the suggestions concerning the wxEntry problem I was having.  I
changed main.c to a c++ file and commented out the extern C wxEntry in wx_main.c
c
and all was well.  If you or the wxWindows users are interested the following
are the changes I had to make to get wx161 to compile on an HP 7xx/8xx machine
using HP's C++ compiler:

        * Add the compiler flag +a1 to the options field in src/make.env
          This tells the compiler to be ASNI strict.

        * You _must_ use flex _and_ bison to compile y_tab.c in the prologio
          stuff.  Also I found gcc works best to build y_tab.o.

        * In contrib/xmgauge/gauge.c, change #ifdef 0 to #if 0

NOTE: The standard c compiler cc on the HP will warn you that +a1 is an invalid
      option when building non-C++ files.  Gcc will bomb if that option is used
      when building y_tab.c.  You can hack the makefile or create a new macro
      to provide the proper options.

Thank you,

Bruce

Compiling Sun dynamic libraries

(See also contrib/wxshlib).

From Frank Brueggemann:

From: Frank Brueggemann <fjb@newton.fb5.uni-siegen.de>
Date: Fri, 17 Mar 95 09:07:35 +0100
To: wxwin-users@aiai.ed.ac.uk
Subject: Re: Dynamic libraries on Sparc question from Keith

Yesterday my colleague Dominik and I succeded in compiling 
wxwin as a dynamic library with gnu 2.6.3 and libg++ 2.6.2 for
SunOS 4.1.3. and openwin 3.0.

The behaviour mentioned is a normal result of the dynamic library system,
but it not so obvious at the first moment. It took some time for us 
to figure out what to do. SUN distinguishes between funtional shared
libraries (so called .so files) 
and libraries that exports initialized data (so called .sa files).

If you wish using the wxwin library as a dynamic library you have to
create a libwx_??.sa file too. This is necessary because the files
    src/base/objects_ol/wb_main.o \
    src/base/objects_ol/wb_obj.o \
    src/base/objects_ol/wb_types.o \
    src/x/objects_ol/wx_main.o 
contain such global data. Thus you have to use a command like
ar rv libwx_ol.sa.0.0 \
    src/base/objects_ol/wb_main.o \
    src/base/objects_ol/wb_obj.o \
    src/base/objects_ol/wb_types.o \
    src/x/objects_ol/wx_main.o 

to build this library in addition to the libwx_ol.so.0.0.

I think the compilation is very similar on the SOLARIS OS.
If you need further details please reply.
From Mikhail Tcheznychev:

Sme words about dynamic library for Solaris 2.4 with
gcc-2.7.0

    In make.env, options:

        OPTIONS=-DSVR4 -fPIC

    In src/x/makefile.unx :

$(WXLIB): $(BASEOBJECTS) $(OBJECTS) $(EXTRAOBJS)
	gcc -G -o $(WXLIB)  -h libwx_ol.so.0 $(EXTRAOBJS) $(OBJECTS) $(BASEOBJECTS)
\end{verbaim}


\subsection{I get link errors for wxEntry, LexFromFile etc.}

Sometimes you might get some or all of these symbols undefined when
linking a sample:

\begin{verbatim}
  wxEntry(int, char**)
  LexFromFile
  PROIO_yyparse
  LexFromString
For PrologIO, try setting CCLEX in make.env to use the C compiler, not the C++ compiler. With the wxEntry problem, if all else fails, change wxEntry in wx_main.cpp to main, and don't link with main.o.


I get a link error under SunOS: the symbol XtShellStrings is resolved.

Tako Schotanus (sst@bouw.tno.nl) writes:

I was finally able to solve it by adding the following define
to "make.env" :

  -DXTSTRINGDEFINES

This has the effect that whenever there's a reference in the
sourcecode to XtN..... (XtNiconName for example) a #define with
the proper string will be used instead of a global array containing
the names.

System: SunOS 4.1.3
libXt:  4.10
gcc:    2.5.8
Another cause may be having multiple versions of libraries (such as the Motif library) in your path.


I get a libXmu link or run-time error.

Put -lXmu in your LDLIBS. This library is used by the ComboBox widget; if you can't get rid of the error, try setting USE_COMBOBOX to 0 in wx_setup.h and recompiling wxWindows and the application.


How do I link applications statically with X and Motif libraries?

Sometimes it's desirable to link an application statically, if the recipient of the executable may not have the appropriate dynamic link libraries. The tradeoff is larger executable sizes.

Here are some responses to a query I put to wxwin-users.

If you're doing this on Solaris, try at the end of your $(CC) command

 -Wl,-Bstatic -lXm -lXt -lXmu -lX11 -Wl,-Bdynamic -lgen -lnsl -lsocket

for SunOS - just do -Wl,-Bstatic

for HPUX or AIX I wouldn't worry about it and I'm not sure about
other platforms - Linux might be a problem ...

Hope this helps.

-jb

------------------------------------------------------------------

gcc -static
works for me.

You can also just put the .a files on the command line if you only want 
to link some libs statically, eg
gcc -o prog ob1.o ob2.o /usr/X11/lib/libXm.a  \
	/usr/X11/lib/libXt.a /usr/X11/lib/libX11.a -lm

------------------------------------------------------------------

Just give the  -Bstatic flag to the linker command line, after the -l flags.

Rajive

------------------------------------------------------------------

It's not hard.  If you are using gcc, then supply -static before the list of
link libraries -- i.e. the set of -l parameters (such as -lXm).  If you are
using Sun compilers use -Bstatic.  Just add this flag to the LDFLAGS
parameter in make or imake.  You know you've succeeded when the ldd command
for the created executable returns `statically linked.'

------------------------------------------------------------------

Hi,

> Just give the  -Bstatic flag to the linker command line, after the -l flags.

This is in SunOS, presumably.  On Linux/ELF, it's -static, and
_before_ all -l flags (since you can turn on/off dynamic linking
on a per-library basis).  It's a pity not all Un*x linkers are
the same...

Regards,

Wolfram.

What to do if GCC gives non-wxWindows link errors

Here's a success story from David Starr (dave@doom.sbi.com), who got the following link errors using GCC 2.5.5. He upgraded to 2.6.2.

ld: Undefined symbol 
   _mktemp__FPc 
   ___9streambufRC9streambuf 

Blymn,

I am writing to thank you for your help in carrying me through
to a successful build, at last, of the wxwin 1.63 release.

Especially since the outcome was positive, I thought I would
share with you my interpretations and the specific results
of your recommendations.

You wrote:

 >> One thing that did give me these sorts of problems was a faulty libg++
 >> library.  The problem is that Sun's make handles the output of shell
 >> commands on command lines differently to that of GNU make (Suns dumps
 >> the output as one big argument on the command line while gmake uses
 >> the IFS shell env variable to split the output into arguments).  What
 >> it boils down to is that if you did not compile libg++ using gmake
 >> then the library is seriously broken.  If you try running nm -p on
 >> libg++.a and get a fairly short list of things defined then the
 >> library is broken, if the list goes on and on then look elsewhere for
 >> the problem.

I discounted the suggestion of the faulty libg++ at first because
the indication from running the nm command was that there were lots of
references.  However, as time went along, I became more convinced that
this was the problem, and it was further compounded by libg++ and gcc 
being out of sync.  I had been running gcc 2.5.5.

I went to my sa and asked him to upgrade my gcc.  Being the
enthusiastic sort, he went about upgrading /usr/local/bin/gcc which
clobbered the 2.5.5 compiler in use by about 10 members of our group.
After that was restored, and everyone settled down, I continued.

Our sa then gave me a separate gcc2.6.3.  Then, also thanks to you,
I got by ftp libg++-2.6.2 from prep.ai.mit.edu (no one here seemed
to know the exact site name), and was able to compile
it successfully.  By this time I had forgetton your suggestion to use
gmake, but the result still worked.

 >> Uhh the symbols given are the c++ mangled names.  The GNU binutils has
 >> a name demangler called c++filt.  The names you are having problems
 >> demangle to:
 >> 
 >> mktemp(char *)
 >> streambuf::streambuf(streambuf const &)
 >>
 >> You could try defining these two and see what happens but I doubt if
 >> you will get far.  I still reckon that your g++ lib is stuffed.

However, I still was getting 
  ld: Undefined symbol 
     _mktemp__FPc 

So, thanks to your post, I had learned about c++filt, and was able to 
define mktemp(char*) in my source, resulting in successfully linked
load modules.

Why does the XView or Motif file selector crash?

> Hi, I compiled wxwin 1.61 beta with gcc 2.6.3 on a Sun sparc.  Everything work
s
> except in the hello demo when I try to open the file selector the program 
> crashes.  Any clue on this is appreciated. (The same problem does not
> occur using gcc 2.4.5. Also I use motif 1.2.)

I had the same problem.  I believe it is *not* the fault of wxWindows.
Instead, the problem appears to lie in the librx (regular expression)
code that is distributed with the most recent version of libg++
(2.6.2?) -- at least, that's where it's crashing.

What I did was to delete all the librx code and all references to it
in the libg++ makefiles, then recompile libg++.  (Just for safety's
sake, I recompiled the wx library as well; I wasn't sure whether it
would have picked up any of the librx code.)  When you relink your
application, the regular expression code in the system libraries will
be used instead.  File selectors now work fine for me.

You may be able to achieve the same effect by making sure that libg++
is the absolute *last* library searched by your compiler (after the
system libraries, in particular), but I haven't tried this.

-------------------------+----------------------------------------
   //  Scott Maxwell:    |  
\\//      maxwell@       | ``Unlike most of you, I am not a nut.''
 XX natasha.jpl.nasa.gov |     -- Homer Simpson
Here's another solution that doesn't involve recompiling libg++:

------------------
wxWindow 1.62e
HP-UX arcturus A.09.04 U 9000/887
gcc version 2.6.3
------------------

to extract rx.o from libg++:

ar d libg++.a rx.o

Warning !
In case you created a copy of libg++.a, let say libwx_g++.a, whithout
rx.o (cp libg++.a libwx_g++.a; ar d libwx_g++.a rx.o), but let the 
original version of lig++.a in place not to disturb other users of
the library; be sure to call the compiler from your makefiles as "gcc",
because "g++" is an alias which automatically generates a reference to
libg++ (-lg++). Thus even if you would mention -lwx_g++ in you makefiles, 
your changes might seem not to be operative.
And yet another, even simpler solution:

By the way, I want you to know that libg++ should go before 
libXm.  The way you have it set up in makefile.unx, make.env,
the file - load core dumps in XmCreateFileSelectionDialog.
The reason is that libg++ has a re_create function which 
apparently is the same name as a motif function used by
XmCreateFileSelectionDialog.

David Starr

ULTRIX compilation


Under AIX, wxTheApp does not initialize properly and causes a wxWindows error message.

After getting wxWindows 1.61 (b) to compiler under AIX, Dirk Eller writes

The major problem was the initialisation problem of the wxApp-object
also reported in install/install.txt.
The fix:
  #ifdef __aix
  extern wxApp *wxTheApp=1;
  #endif
doesnt work on my system. It looks also very bad ?

After a little testing I figured out that wxApp isn't initialized at the time
when main() (->wxEntry) is called.
The fix is to move the call of main() to the file where the global object
is supposed to be created. (e.g. hello.cpp)

The reason is that (stroustroup) c++ compiler does not HAVE to create a global
object before main, but only before any functions are called in the file that
the object is in. (thanks Eugene)
The fix is not very elegant, but it works. 

When deleting a frame or dialog box, the program crashes.

On some systems, you should not use the delete operator to delete frames or dialog boxes. Use wxPostDelete instead, to get the object deleted when X has finished processing all other messages.

Note for version 1.66 and later: wxWindow::Close has been introduced for delayed deletion of frames and dialogs. Please use this instead of wxPostDelete.


How can I compile PROLOGIO successfully under UNIX?

Check the CCLEX variable in src/make.env; set it to use a bog-standard (or GNU) C compiler for compiling LEX-generated files.

Using FLEX instead of LEX sometimes helps, too.

Most of the warnings when compiling PROLOGIO are spurious; however, there may be an error buried inside the warnings. If so, you may need to change a prototype in a generated .c file to get it compiled. Hopefully this type of error is getting much rarer now.


How can I compile wxXPM successfully under UNIX?

Check the XPMCOMPILER variable in contrib/wxxpm/makefile.unx; set it to use a bog-standard (or GNU) C compiler.


I get libXmu.so.4 (or similar) not found on linking.

This library is currently only needed for the ComboBox implementation. If this is causing trouble, switch off ComboBox compilation in wx_setup.h and src/x/makefile.unx, and recompile.


Why do I have compilation problems compiling wb_list.cpp on Solaris?

If you get this kind of message:

wb_list.cpp: In method `wxList::wxList(wxObject * ...)':
wb_list.cpp:178: `__builtin_va_alist' undeclared (first use this function)
wb_list.cpp:178: (Each undeclared identifier is reported only once
wb_list.cpp:178: for each function it appears in.)
wb_list.cpp:186: warning: implicit declaration of function `int __builtin_va_arg_incr(...)'
try editing the makefile and setting your OPTIONS (XView/Motif) or FLAGS (Xt) as follows:

FLAGS = -O2 -D__EXTENSIONS__ -Dsparc -Dlint -DSVR4 -Wall -Dwx_xt # (or -Dwx_motif for Motif)

Why do I get an undefined virtual table error?

If you get something like this:

 ld: Undefined symbol 
    wxView virtual table
    wxCommand virtual table
    wxFileHistory virtual table
    ...
when compiling with g++, it could be that the relevant file (here, src/base/wx_doc.cpp) is in DOS CR/LF format. Remove the extra characters with a dos2unix utility, or by zipping up the file and unzipping with the -a option, or by using a text editor, and recompile.


Unresolved references using Linux and SWiM Motif 2.0

If you get unresolved references such as:

Shell.o(.text+0x2ba0): undefined reference to `SmcModifyCallbacks'
you may need to add /usr/X11R6/lib to your XLIB variable in src/make.env.


Duplicate symbol error when compiling with xlC on AIX 4.1.4

It's not necessary to use "-lCns -lbsd" when linking wx applications using xlC (AIX 4.1.4).

make.env:

# AIX: -lCns -lbsd
#COMPLIBS=-lCns -lbsd
COMPLIBS=