Recent blog entries for juancpaz

The project fspaix (Free Software Porting to AIX) seems that it has started. Thanks to Gerard Eviston. It has a AIX5 box and it has joined to the project.

We would be very glad if more people want to join to our project (with more boxes AIX if it is possible)

Another thing, I have seen that my Certification in Advogato has fallen from Apprentice to Observer. Is this a normal behavior or is something wrong in mod_virgule?

haruspex

Thank you for you interest. Well, that isn't the project I created Free Software Porting to AIX, that AIX Port project is, I think, dead, without activity since a long time ago. I have spoken with Felix Mathais, his project leader, and he have left the project

We will need AIX5x 64 bits at least, IBM wont support AIX <= 4.3 from 01/01/2004. I think we will can use a 64 bits machine to generate 32 bits code, IBM says this is possible, and I have successfully done it

If all is right, we will compile and test software in aix, then we'll report and deliver to suited community. If things goes wrong, we'll find a solution, even changing code, and we will report it to comunity, too.

If you have a sourceforge user, please, let me know, I will join you to fspaix with manager rights

I have created a new project for AIX Porting in sourceforge, as long as I know sf don't provides a prowerpc-aix platform in its compiler farm. Somebody knows how can i get it? I have already done a support request for it

If somebody want to help...wellcomed and thanks.

At the moment we can only compile information like tips&tricks, experiences, documentation, and so on, about AIX Porting.

23 May 2003 (updated 23 May 2003 at 09:09 UTC) »
Building Apache 2.0.45 in AIX51 64 bits

This is about problems I have foud building Apache 2.0.45 in AIX 5.1 64 bits. First in all, when i build apache, i use a environment like this:

PATH=$AUTOTOOLS:$PATH
CC="xlc_r"
CXX="xlC_r"
CPP="xlC_r -E"
LDFLAGS="-blipath:/usr/lib:/lib"
CFLAGS="-q64 -I. -I/usr/vacpp/include -qstrict -qlanglvl=extended -D_LARGE_FILES -g -qfullpath"
LTFLAGS=" "
OBJEXT=".o"
LIBEXT=".so"
AR="/bin/ar"
AR_FLAGS="-rv"
RANLIB="/bin/ranlib -t -X64"
OBJECT_MODE=64
LIBPATH="/usr/lib:/lib"
Note i use autotools to create configure files, those delivered with apache don't work right

Well, next, i create a clean build system
cd $source_dir
./buildconf
I don't execute build/binbuild.sh for to several reasons, as you can see below I need to change some things in middle of process... btw, apr and apr-util don't know Apache Layout, then, i usually set LAYOUT=apr and LAYOUT=apr-util in respective configures, just before sed command use it.

Next, I modify server core.c to apply a patch to solve a xlc problem as describe by Jeff Travick in "Status of Apache 2.0 on AIX"

Then, depending on environment you have set, probably, you could build all, however, if you do that now, you will probably find some problems.

1. Where is libexpat.so? nowhere, it won't generate
2. httpd won't import symbols
3. modules and apr-util libraries will have absolute paths in its loader sections

To solve this, I must after execute configure manually, modify makefiles before make. So, I execute configures:
cd $source_dir
./configure --enable-layout=Apache --prefix=$source_dir/bindist --enable-mods-shared=most \
--with-expat=$source_dir/srclib/apr-util/xml/expat --enable-static-support</tt>
1. Fix libexpat.so generation

srclib/apr-util/xml/expat/lib/Makefile changed:
...
install: $(LIBRARY) $(APIHEADER)
...
$(LIBTOOL) --mode=install cp $(LIBRARY) $(DESTDIR)$(libdir)
...
I usually use libtool from apr:

...
LIBTOOL = $(SHELL) $source_dir/srclib/apr/libtool
...
2. Fix httpd import symbols

To fix this, modify build/config_vars.mk and set HTTPD_LDFLAGS to get httpd.exp file:
...
HTTPD_LDFLAGS = -bI:$my_source_dir/server/httpd.exp
...
3. Fix absolute path references in libraries

I really hate this, finding absolute path references in loader section of libraries after generating a kit:

$ dump -X64 -Hv libparutil-0.so
libaprutil-0.so:
...
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER
0      absolute_path:/usr/lib:/lib
1      absolute_path/bindist/lib libexpat.so
2                                    libiconv.a          shr4_64.o
3      absolute_path/bindist/lib libapr-0.so
4                                    libc.a              shr_64.o
Adding -blibpath=/usr/lib:/lib to LDFLAGS isn't sometimes enought to solve this. Sometimes, libtool removes this flag. If configure generated Makefiles with libraries full names in LIBS, or libtool doesn't find libraries in .libs, it will search for it in another places and full paths will be generated

This problem mainly affect module libraries and libapr-util.so, the trick to solve it is, i think, to give to libtool flags in following way:

...
LDFLAGS=-L$source_dir/srclib/apr -L$source_dir/srclib/apr-util \
-L$source_dir/srclib/apr-util/xml/expat/lib -blibpath:/usr/lib:/lib
...
LDLIBS=-lapr-0 -laprutil-0 -lexpat
...
For modules, it could be enought modifying build/config_vars.mk, for apr-util, I didn't find the right place to properly fix it, so I dump libtool command to a log, then, after make and make install, I launch the xlc command manually, some like this:
xlc_r -o .libs/libaprutil-0.so.0.9.3  \
buckets/apr_buckets_file.o buckets/apr_buckets_pool.o buckets/apr_buckets_flush.o buckets/apr_buckets_refcount.o \
...
misc/apr_rmm.o misc/apr_reslist.o misc/apr_queue.o misc/apu_version.o strmatch/apr_strmatch.o xlate/xlate.o \
-L$source_dir/srclib/apr-util/xml/expat/lib/.libs -lexpat  \
-L$source_dir/srclib/apr/.libs -lapr-0 \
-liconv -lm -lnsl   -lc  -Wl,-brtl -Wl,-bnoentry -Wl,-bexport:.libs/libaprutil-0.exp \
-Wl,-G -blibpath:/usr/lib:/lib
Something strange ... make build .so right, but make install "relinks" libaprutil-0.so (why?) taking other flags and producing a library with a wrong load header.

Another problem is about mod_dav, after a proper build and install, I start httpd and looks ok, but when i try to connect, a core is generated ... debugging, I have found that a request is arriving to mod_dav. This request isn't for mod_dav, probably, mod_dav was loaded too soon, or another module that would should have processed the request previously, hasn't done it. I have found two solutions for this.

1. Modifying modules/dav/main/mod_dav.c

static int dav_fixups(request_rec *r)
{
   dav_dir_conf *conf;
   ...
   if (strcmp(r->handler, DAV_HANDLER_NAME) != 0)   /* This is the fix, if program is allowed to continue */
      return DECLINED;                              /* without this check, a core could be generated      */
   
   conf = (dav_dir_conf *)ap_get_module_config(r->per_dir_config,
      &dav_module);
   if (conf->provider == NULL) {                   /* This could become a core if conf isn't a valid pointer */
      return DECLINED;
   }
   ...
}
2. A colleague told me a different solution, this is to statically link mod_dav.a into mod_dav_fs.so, something like this:
xlc_r -o .libs/libmod_dav_fs.so.0.0.0  \
mod_dav_fs.o dbm.o lock.o repos.o ../main/.libs/libmod_dav.a  \
-lc  -Wl,-bnoentry -Wl,-bexport:.libs/libmod_dav_fs.exp -Wl,-G -blibpath:/usr/lib:/lib
... and, well, it is true, httpd don't crash after this ... but I don't understand why this is done ... if we build a different provider, must we statically link mod_dav too? ... I dont know if mod_dav will work properly.

This is all, I have finally create several scripts to pack .tar.gz file in the usual way, taking parts from original build/binbuild.sh, ... previously I copy sources to local directory in order to remove temporary .nfs files, taking care that my script sets original paths in httpd-std.conf, in order to ensure a future proper execution of install-bindist.sh.

From Apache 2.0.39 (from bug in core.c), I have seen that AIX have been forgotten by the community, I think that if Apache for AIX's build system isn't fixed now, the next apache versions could probably become too hard to build.

29 Apr 2003 (updated 29 Apr 2003 at 14:13 UTC) »
Apache 2.0.45 for powerpc-ibm-aix5.1 64 bits

With a lot of problems, I have got build and properly run Apache 2.0.45 on AIX 5.1 64 bits. I have used xlc. Next, I will try fix Apache build mechanism on AIX 5.1

Soon, I will post an article about problems I have found and I will describe I have done to solve it.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!