brushOp.c makes reference to xaw_incdir
Brought to you by:
aermartin
Menu
▾
▴
#12 brushOp.c makes reference to xaw_incdir
So in my setup, i need to build libXaw3dXft-1.6.2b in order to build version 2.9.9.4 of xpaint. (I'm using ElementaryOS, which is a derivative of Ubuntu 12.04, for which there does not seem to be a suitable libXaw3dft package pre-built.)
I configure libXaw3dXft by "./configure --prefix=$HOME/install/xaw" (without the quotes, of course). After configuring, it apparently builds and installs ok. In particular, it makes the directory ~/install/xaw/include/X11/Xaw3dxft/. But it does not make the directory ~/install/xaw/include/xaw_incdir/.
On the other hand, brushOp.c really wants the directory xaw_incdir to exist (it has #include directives for "xaw_incdir/Box.h" and other similar ones).
Now i can force the xpaint build to go through by manually creating a symbolic link xaw_incdir that refers to X11/Xaw3dxft.
But i think that is probably not the intention of the code.
(I'm still in the process of working out a smooth build process for this situation of having to refer to my own Xaw3dxft instead of a system one.)
So: thanks in advance for a fix, if this is indeed a bug, or for help in the alternative case.
BTW, my configure command for xpaint itself is:
PKG_CONFIG_PATH=$HOME/install/xaw/lib/pkgconfig LDFLAGS=-L$HOME/install/xaw/lib CPPFLAGS=-I$HOME/install/xaw/include/ ./configure --prefix=$HOME/install/xpaint
although i think the PKG_CONFIG_PATH environment variable may be being ignored, because it seems to be absolutely essential to assing both LDFLAGS and CPPFLAGS. (Further, the make does not allow a space after the -L in the LDFLAGS, although the configure does not issue a warning if you do include a space, e.g. LDFLAGS="-L $HOME/install/.......".)
To recap: i'm using an ubuntu 12.04 derivative for which, apparently, there is no prebuilt xaw3dxft package. I installed xaw3dxft in what can only be described as a non-standard location, and had trouble compiling xpaint with it.
Summary: i think i have a solution for the problem of using xaw3dxft that is in a non-standard location, by modifying configure.ac and Makefile.am; i've attached these two files, plus a new version of main.c (for an unrelated issue), in a tar file.
Long detailed discussion:
So the ultimate deal seems to be that the PKG_CONFIG_PATH environment variable is not consulted by the existing build apparatus for xpaint. Thus if you have xaw3dxft in a non-standard location (for example, because there is no package and you don't want to write in the standard directories absent a package), you cannot alert the xpaint build system to that fact through the PKG_CONFIG_PATH variable. However, adjusting that variable is the most natural way to communicate where to pick up the include files and libraries.
The solution, imvho, is to modify configure.ac and Makefile.am to pay attention to PKG_CONFIG_PATH, and use them in setting up the libraries to use and symbolic links to directories to form.
These two files are in the attached tar ball.
There's one other file there, a slightly modified version of main.c.
There's a totally unrelated problem with main.c, which is hinted at by the warnings it generates at compile time (it generates some unused value warnings). So i modified main.c so that it uses all those formerly unused return values, and in one case this clips a redundant line out of some "help" info.
Supposing that you've installed your xaw3dxft software in $HOME/install/xaw, then the sequence of operations would be:
(1) copy in the 3 files
(2) autoreconf
(3) PKG_CONFIG_PATH=$HOME/install/xaw/lib/pkgconfig LDFLAGS=-Wl,-rpath=$HOME/install/xaw/lib ./configure --prefix=$HOME/install/xpaint
(4) make
Note that the configure apparently needs to be run in the source directory.
This is not desirable, but i did not try to fix the issue (as it does not stop compilation).
To run, you need to use a command like
./xpaint -sharedir share
in the directory where it is built.
Finally note that although i've specified a prefix for installation ($HOME/install/xpaint) in the configure command above, we don't really have a good method of installation that can avoid use of sudo. (The xpaint build apparatus really wants to install the applicaton defaults in a system area, regardless of the value of prefix.) I don't think that's exactly right, as entirely apart from requiring root access, it prevents installing multiple simultaneous different versions of xpaint, but there's more than one way to fix it. So that seems like more of a policy issue.
Please let me know of any issues with this code or approach (i'm not sure exactly how to submit anything to the maintainer, but wanted to put this out in case anybody else is in my boat).
dan
On Sun, Jun 09, 2013 at 06:12:07AM +0000, dan wrote:
Many thanks for your efforts towards fixing these small issues - and apologies for not reacting earlier, actually I have been extremely busy in the last period; please note that the promised tar file was actually not attched.
In principle, the latest version of libxaw3dxft comes with a pkgconfig hook, so you could indeed just use it in case you are using a non standard location. Fixing the build process, in any case, is only a matter of setting an ad hoc symbolic link for xaw_incdir, which one can fix essentially with a one line command in the Makefile or configure scripts (or distro specific build scripts).
Best,
Jean-Pierre Demailly
Thanks Jean-Pierre for your reply despite your busy schedule.
I may indeed be running the configure script incorrectly! :)
(I believe that the tar file is attached to the comment, or, at least, it appears that way in firefox.)
Best regards!