[xml] CFLAGS and build process and libxml2-2.4.12.tar.gz

[stan boehm philips com]

Sorry for this long winded diatribe about CFLAGS but, I have fallen and can't get up.

I searched the archive and did not find that anyone else was having problems
like these.  Since no one else seems to have any problems with 2.4.12, I must conclude I
dont know what I am doing.  Can anyone out there give me a hint as how to 
get around the following problems - all relating to CFLAGS?

We use QNX and the Watcom compiler.  Due to a long history, we are forced to use
some undesirable compiler options.   Our last port was libxml2-2.3.13 and it was very
easy.  It went something like this:

*) CFLAGS  - It used to be that I could run configure and make as follows,
             and I believe this follows the recommended practice in the FAQ.
                $config_opt is set to a bunch of --without-options - threads, shared mem, iconv etc.

    cd to libxml2-2.3.13

    ./configure $config_opt 2>&1 | tee QNX_conf.log

    export CFLAGS='-g "-Wc, -zp4 -ei"'   # add special WATCOM flags that we use.

    /bin/make 2>&1 | tee QNX_make.log

make would inherit the desired CFLAGS as part of the UNIX environment,
and all was wonderful.

But now this does not work because config.status is referenced
in the Makefile and it defines CFLAGS for the Makefile.
NOTE: I am guessing there are many advantages in doing it this way,
      but so far, I do not see any.  Please read on.

So far the only way I have found to get around this is as follows
and it has many bad side effects.

After running  configure, I edit the sed line in config.status
that is used to set CFLAGS. 
For the most part this seems to work, but there are several problems.
The use of config.status seems to be something new introduced since 2.3.13.

At first I thought that the proper fix would be to modify configure
    to set CFLAGS the way we need it based on a command line argument.
    However, I soon ran into many problems and it was clear that changing
    CFLAGS would have to be done just prior to building config.status.
    Therefore, I choose to simply modify config.status in the interest to
    complete the build process.
    When I tweak CFLAGS in config.status so that libxml compiles the way 
    we need it, I get the following failure in xmllint.
    ....
(cd .libs && rm -f libxml2.la && ln -s ../libxml2.la libxml2.la)
cc  -DHAVE_CONFIG_H -I. -I//25/home/stan/p4_work/wfree/libxml2-2.4.12 -I. -I//25/home/stan/p4_work/wfree
/libxml2-2.4.12/include -I./include       -g "-Wc, -zp4 -ei" -c xmllint.c
/bin/ksh ./libtool --mode=link cc   -g "-Wc, -zp4 -ei"  -o xmllint  xmllint.o ./libxml2.la    -lm -lsock
et  -ldir
cc -g " -zp4 -ei" -o xmllint xmllint.o  ./.libs/libxml2.a -lm -lsocket -ldir
cc warning: cc: cannot find library 'm'
cc warning: cc: cannot find library 'dir'
Error(3033): directive error near '-ei'   <--------------------------------------- ?????
make[2]: *** [xmllint] Error 1
make[2]: Leaving directory `/home/stan/p4_work/wfree/libxml2-2.4.12'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stan/p4_work/wfree/libxml2-2.4.12'
make: *** [all-recursive-am] Error 2


I find this very strange as all the other *.c files compile fine, just as they did 
in the past.

If I remove -Wc, -zp4 -ei from CFLAGS in config.status, then this problem
disappears, but then all the c files get rebuilt the wrong way.  So I am between
a rock and a hard place.  Without solid knowledge, it appears to me that the use
of config.status in Makefile has created a vicious circle, but wait there is more.
I am guessing that each .o file is dependent on config.status, so that my edit
forced make to rebuild them all.
        
If I cd to ./example and try to make  gjobread, it fails the same way.
After removing my junk from CFLAGS it builds nicely, but wont run.

When I run it it coredumps:

gjobread  gjobs.xml

Sorry I do not have time to provide more on this core dump at this time.
I am hoping that the coredump will go away when I learn how to build 2.4.12
properly.

Finally, 

*) make clean and make distclean are inconsistent.  Sometimes they work
   sometimes they dont.

   wfree/libxml2-2.4.12 :stan 75>make clean

/bin/ksh ./config.status --recheck
running /bin/sh //25/home/stan/p4_work/wfree/libxml2-2.4.12/configure  --disable-shared --without-iconv
--without-ftp --without-http --without-catalog --without-docbook --without-xpath --without-xptr --withou
t-xinclude --without-debug --without-threads i386-pc-qnx --no-create --no-recursion
loading cache ./config.cache
checking host system type... i386-pc-qnx
checking for a BSD compatible install... //25/home/stan/p4_work/wfree/libxml2-2.4.12/install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
configure: error: source directory already configured; run make distclean there first
make: *** [config.status] Error 1

   wfree/libxml2-2.4.12 :stan 76>make distclean

/bin/ksh ./config.status --recheck
running /bin/sh //25/home/stan/p4_work/wfree/libxml2-2.4.12/configure  --disable-shared --without-iconv
--without-ftp --without-http --without-catalog --without-docbook --without-xpath --without-xptr --withou
t-xinclude --without-debug --without-threads i386-pc-qnx --no-create --no-recursion
loading cache ./config.cache
checking host system type... i386-pc-qnx
checking for a BSD compatible install... //25/home/stan/p4_work/wfree/libxml2-2.4.12/install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
configure: error: source directory already configured; run make distclean there first
make: *** [config.status] Error 1

        OK - this is because my environment had CFLAGS set to  '-g "-Wc, -zp4 -ei"'

     libxml2-2.4.12 :stan 206>echo $CFLAGS

                              -g "-Wc, -zp4 -ei"

        So, sometimes the process is sensitive to my environment, and sometimes not.

        "make clean" should not be sensitive to what I have in CFLAGS,
        nor should  "make distclean" but it is now.

But again this seems related to 
               /bin/ksh ./config.status --recheck

And of course make install does not work for similar reasons, 
so I completed the install by hand.


So I have two questions:

1) What is the correct way to solve this problem ?

2) Where do I go to get a good primer on the theory of how this GNU
   build process works?  

   It seems to me that many people struggle with
   this process every time a new version of libxml is released.  Perhaps
   the FAQ could provide a few hotlinks or references to help enlighten us 
   lesser grunts.

Granted I am on QNX using Watcom, but I do not think this has anything to
do with the way CFLAGS is now trapped in config.status.  

Yes I finally got libxml built, and I finally got our software to link to
to  2.4.12.  However, I am not able to run our reqression tests.  I can create
XML documents, but I can not read them(core dump).  Before I dive deeper into those
problems, it seems that the issue with CFLAGS should be addressed first.  Again, I
am hoping these core dumps will disappear when I learn how to build 2.4.12 properly.

If it was not for catalogs and some other new features, I would stay with 2.3.13.
But it is not wise to fall to far behind.