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
Yes, it's in the contrib/wxshlib directory of the distribution, from 1.66 onwards.
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
Try adding -lstdc++ to the link flags.
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).
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.
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 !
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
(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.
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:
export OPTIONS OPTIONS=-fPIC
WXLIB = $(WXDIR)/lib/libwx$(GUISUFFIX).so.0 $(WXLIB): $(OBJECTS) $(BASEOBJECTS) ld -G -o $(WXLIB) $(OBJECTS) $(BASEOBJECTS)where the ld line replaces the ar+ranlib command.
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 $@
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.oAlso:
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
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
(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 LexFromStringFor 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.
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.8Another cause may be having multiple versions of libraries (such as the Motif library) in your path.
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.
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.
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.
> 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 SimpsonHere'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
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.
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.
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.
Check the XPMCOMPILER variable in contrib/wxxpm/makefile.unx; set it to use a bog-standard (or GNU) C compiler.
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.
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)
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.
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.
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=