First the long winded part. Skip this paragraph to go directly the problem.
I’m trying to get recent versions of Apache (2.+), PHP (5), and MySQL (Don’t care) to all work together. I’ve found no precompiled versions, so I’m left to putting this all together myself. Apache(2.+) was no problem. PHP(5) is not fun. First I needed to get an up to date version of iconv compiled. Then during the make of php, I got a very scary warning.
*** Warning: This system can not link to static lib archive
/usr/local/lib/libiconv.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.

A hah! libiconv was not compiled for shared use. Hmmm, why not? I went back and watched the ./configure carefully. It indicates that libtool is not set up for shared libraries.

checking if libtool supports shared libraries… no
checking whether to build shared libraries… no
checking whether to build static libraries… yes

Ok, so I uninstall libtool, and download the latest. I configure it with --enable-shared, make it, and install it. I go back to iconv and try again. No luck, the ./configure script insists that libtool is not set up for shared libraries.

Anyone have any suggestions. I don’t even know what I’ll use iconv in php for, but I’m currently stumped.

Have you looked at the QOpenCD project mike.qnx.org.ru/qopencd/software.html ?

They have lots of precompiled packages for QNX 6.3. I believe their libiconv has the shared libs. Also, if you use their libtools suite of tools, “configure” test should be able to build the shared lib.

Good luck.

Noc,

No I didn't know about this project.  Thanks so much, I'll check it out.

Mitchell

I thought it would be nice to follow up on this, in case anyone follows in my tracks. I tried the QOpenCD project’s iconv, but without pointing any fingers, it just didn’t help. I downloaded their libtools and while they seem to have a more up to date version, it too did not seem to help much. I proceeded then to dig at the problem again. Debugging 800,000 byte shell scripts is not fun. After much sweat I found the problem. The iconv package has two configure scripts, one calls the other. Both have this problem. In case statements, the string nto-qnx) appears numerous times. Unfortunately the string that “nto-qnx” is matched against is now “nto-qnx6.3.0”. I changed all these strings to “nto-qnx*)” and all was finally well, at least as far as creating shared libraries from iconv.

Well the story isn’t quite over. I sent an email to the author about the problem. I got a nice reply indicating that 1.9.2 was not the latest version of iconv, but rather 1.11 is, and the problem is already fixed. I had to backtrack to find that at the gnu.org website where I originally found the tarball, that they still have 1.9.2 listed as the latest, even though they stock the later version. Oh, well, a week here and week there.

But Dependency Hell is not over yet. With the latest iconv, the php Make script makes libphp5.la. But now “make install” fails as follows:

make install

Installing PHP SAPI module: apache2handler
/usr/local/apache2/build/instdso.sh SH_LIBTOOL=’/usr/local/apache2/build/libtool’ libphp5.la /usr/local/apache2/modules
/usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/
cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la
cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a
ranlib /usr/local/apache2/modules/libphp5.a
chmod 644 /usr/local/apache2/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish /usr/util/php/php-5.1.4/libs’
Warning! dlname not found in /usr/local/apache2/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache2/modules/libphp5.so
/usr/local/apache2/modules/libphp5.so: No such file or directory
apxs:Error: Command failed with rc=65536
.
make: *** [install-sapi] Error 1

I know that the script instdso.sh calls apxs, which is supposed to create the libphp5.so file, which apparently fails. I can’t figure out why. My guess is that some included module is not compiled with -fPIC to make it relocatable, but I haven’t a clue right now on how to figure this out. I know this is rather obscure stuff, but if anyone with some experience in this weird area knows what’s going on I’d appreciate some pointers. BTW, this is all in the service of getting Apache/PHP/MySQL recent versions working on QNX 6.3.0. This should be doable, right?

Thanks

My appologies for the previously messy post.  Here is the important stuff again:

# make install
Installing PHP SAPI module:       apache2handler
/usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules
/usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/
cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la
cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a
ranlib /usr/local/apache2/modules/libphp5.a
chmod 644 /usr/local/apache2/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish /usr/util/php/php-5.1.4/libs'
Warning!  dlname not found in /usr/local/apache2/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache2/modules/libphp5.so
/usr/local/apache2/modules/libphp5.so: No such file or directory
apxs:Error: Command failed with rc=65536
.
make: *** [install-sapi] Error 1
#

I know that the script instdso.sh calls apxs, which is supposed to create the libphp5.so file, which apparently fails. I can’t figure out why. My guess is that some included module is not compiled with -fPIC to make it relocatable, but I haven’t a clue right now on how to figure this out. I know this is rather obscure stuff, but if anyone with some experience in this weird area knows what’s going on I’d appreciate some pointers. BTW, this is all in the service of getting Apache/PHP/MySQL recent versions working on QNX 6.3.0. This should be doable, right?

Thanks
[/code]

Apparently, you only generated the static lib libphp5.a. Apache wants the shared lib libphp5.so.

I remember last time I had to tweak the “configure” script in php so that it can generate shared libs. Check the output of your php’s configure and see if it says “shared libs: yes”.

Ok, well I set -enable-so and I checked that php is creating shared libs. The “lib” libphp5.la is created. I’m not an experit with libtools but my understanding is that this is the stand in for the shared lib. I’m posting here. It is set up as if there is no need for a separate “shared” lib. 2 This suggests to me that libtools is not set up correctly, but the libtools that the make uses is created on the fly by configure.

libphp5.la - a libtool library file

Generated by ltmain.sh - GNU libtool 1.5.20 (1.1220.2.287 2005/08/31 18:54:15)

Please DO NOT delete this file!

It is necessary for linking the library.

The name that we can dlopen(3).

dlname=’’

Names of this library.

library_names=’’

The name of the static archive.

old_library=‘libphp5.a’

Libraries that this one depends upon.

dependency_libs=’ -R/usr/local/lib -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -L/usr/local/lib /usr/local/lib/libiconv.la -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket -lz -lm -lsocket /usr/local/lib/libxml2.la -lz -lm -lsocket -lz -lm -lsocket’

Version information for libphp5.

current=0
age=0
revision=0

Is this an already installed library?

installed=yes

Should we warn about portability when linking against -modules?

shouldnotlink=yes

Files to dlopen/dlpreopen

dlopen=’’
dlpreopen=’’

Directory that this library needs to be installed in:

libdir=’/usr/util/php/php-5.1.4/libs’

One more minor point, the configure script says YES to shared libs, and NO to static ones. Go figure?

.la file is not the shared lib. .so file is.
Per Wikipedia:
The .la files sometimes found in the library directories are libtool archives, not useable by the system as such.

Below is a snip from the configure output from my old archive when I built php4 on qnx 6.2. In your log, you should at least see the “yes” for “linker supports shared lib”, “libtool supports shared lib” and “whether to build shared lib”:

…
checking whether the linker (/usr/bin/ntox86-ld) supports shared libraries… yes
checking how to hardcode library paths into programs… immediate
checking whether stripping libraries is possible… yes
checking dynamic linker characteristics… QNX ldqnx.so
checking if libtool supports shared libraries… yes
checking whether to build shared libraries… yes
checking whether to build static libraries… no

That was not my point. I know the .la file is not a shared lib itself, but it effectively is to libtool, just as a .lo file is a shared object file.
It’s true the .lo file is not usable as a .o file, but in the case of QNX,
it references .lib/foo.o which is the sharable version.

Yes I see this. When the makefile tries to link the shared library it gets the following message:

*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

The second warning seems to be the problem. Unfortunately the message tells me nothing about what inter-library dependencies it could not satifsy. It makes the title I chose for this topic seem all the more appropriate. There was nothing else in the configure/make process that alerted me to something wrong. I tried removing any external dependencies, such as MySQL or iconv, but this did not help either. It seems that something is broken. I’m happy to go looking, but it seems like I have to learn this all as I go. My goal in all this was have a platform to learn PHP/MySQL web building, and here I am getting an education in libtool/configure/apxs/etc. Sorry for ranting, you all know what it’s like. I do really appreciate the help.

As I mentioned in below post
openqnx.com/PNphpBB2-viewtopic-t6163-.html

once you have installed the new libtools package, you need to regenerate your php’s “configure” so that it can create shared libs for you.

Ok, sorry about my inattentiveness. This gets me very very very close.
I can almost taste it. I still feel like I’m searching around in the dark though. I did download the new libtools, but didn’t know about libtoolize, nor aclocal nor autoconf.

I run aclocal, and nothing happens. I track the problem down. aclocal is in /usr/bin. It is a perl script. It references #!/usr/local/perl. But perl is in /opt/bin/perl. That was easy to fix. I run libtoolize and it gives me some warnings.

libtoolize -f -c

/usr/bin/libtoolize: continue: cannot continue
/usr/bin/libtoolize: continue: cannot continue
usr/bin/libtoolize: continue: cannot continue
libtoolize: copying file ‘./config.guess’
.etc …

Now I run aclocal:

aclocal

aclocal: macro ‘LT_AC_PROG_SED’ required but not defined

aclocal does not run, and so if I continue and run configure, I get an error during make from libtools.

libtool: version mismatch error. This is libtool 1.9f but the
libtool: definition of LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 1.9f
libtool: and run autoconf again

I nervously think that I am one problem away from success.

I google LT_AC_PROG_SED and I conclude from the many postings similar to my problem that this is very common. But all the googled references say nothing about what to do about it. They imply some kind of installation version problem with various components. Does anyone know how to cure this problem?

Thanks

Well as I discover things, I think I should keep this up to date.
On a whim, I decide to just remove the line in acinclude.m4 that causes the error with LT_AC_PROG_SED.
Amazingly enough, this seemed to work. At least I’ve gotten no other complaints about SED.
Unfortunately aclocal did get some warnings and errors:

configure.in:141: warning: AC_PROG_LEX invoked multiple times
configure.in:168: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:198: error: possibly undefined macro: AC_MSG_RESULT
configure.in:1229: error: possibly undefined macro: AC_PROG_LIBTOOL
configure:125284: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF

I let the configure run, but it seems that aclocal did not complete configure, as the following error occurs:

checking whether dlsym() requires a leading underscore in symbol names… ./configure[125284]: syntax error: `newline’ unexpected

Any suggestions? Maybe I need to re-port the latest versions of all these configuration utils again?

It seems to me that you have multiple versions of tools installed, and there are some mismatch issues.
try
which -a libtoolize aclocal autoconf

I would suggest you clean up your system a bit, and make sure you have “libtool”, “automake”, “autoconf”, and “perl” all downloaded from the same place (eg: QOpenCD project) so that they can match each other in version dependencies.

Once you have all those tools cleared up, you can try php build again.

Good luck.

This could be a long story.

Removing all the current versions and downloading the latest
from mike.qnx.org.ru/qopencd/repository did not work.
Without going into great detail, aclocal and autoconf both burped,
and the configure file was never created properly.

I went back to square one.
I downloaded the following program/versions, mostly from www.gnu.org.

m4 1.4.6
sed 4.1.5
perl 5.8.8
libtool 1.5.22
iconv 1.11
automake 1.9.6
autoconf 2.60

The order in making this is important, but not hard to follow.
If you make a mistake, for example creating autoconf before m4
you get a nice error message telling you to create m4.
All of these except per use the standard procedure:

./configure

make

make install

Perl has it’s own procedure documented in the file INSTALL.

There were a few minor problems compiling. For example, somewhere
in sed I needed the following:

#ifdef QNX
typdef enum { false=0, true=1} bool;
#endif

Those are all the problems I can think of right now.
There is a special note about perl. While the instructions
in the INSTALL file worked, 5 tests out of 200+ failed.
I got cold feet and downloaded 5.8.6 from mike.qnx.org.ru/qopencd/repository.
The test diagnostics suggest that the problem might be minor, and only
a correct env variable might be needed. I’ll check further later, maybe.

Ok, so finally now back to php 5.1.4.

libtoolize -f -c (worked)

aclocal (worked)

autoconf (worked)

./configure … (worked, sort of)

When I first tried make, I immediately got an error when libtools was run.
This turned out to be a strange formation from Makefile

-I"/lib

The problem was an unterminated quote mark.
I removed this weird token from the Makefile, and all started making
properly.

A few source files needed some bandaids, in particular:

php-5.1.4.x/ext/iconv/iconv.c (a few case problems)
ext/mysql/php_mysql.c (needed ushort defined)
ext/posix/posix.c (makedev for QNX 6.3 has 3 args,not 2
insert a zero for first)
main/php_ini.c (problem with missing alphasort)

Then, just when I thought I was finally going to get a valid libphp5.so:

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
copying selected object files to avoid basename conflicts…

The same blasted message, and no .so file.

I had only one more thing to try. I uninstalled libtool 1.5.22,
and installed 1.9f from mike.qnx.org.ru. I ran
libtoolize, aclocal, and autoconf again. This time I got the
same errors that stopped me the first time:

autoconf

configure.in:141: warning: AC_PROG_LEX invoked multiple times
…/…/lib/autoconf/programs.m4:755: AC_DECL_YYTEXT is expanded from…
acinclude.m4:2056: PHP_PROG_LEX is expanded from…
configure.in:141: the top level
configure.in:168: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:198: error: possibly undefined macro: AC_MSG_RESULT
configure.in:1229: error: possibly undefined macro: AC_PROG_LIBTOOL
configure:139824: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF

This brings up a question about the mike.qnx.org.ru/qopencd/respository
version of libtools. It lists its version as 1.9f. The latest version
at www.gnu.org is 1.5.22. Does this mean someone did some special
work on 1.9f for QNX 6? If so, it seems like it is out of date.
I’ve found references at google about these macros, but no answer other
than “broken toolchain”.

I’m not finished yet, but I have made some significant progress.
I found out why the php compile of a shared library fails.
I created my own Makefile for just the libphp5.la library,
and removed the -L and -l options. This allows the creation
of a shared library. The install then works fine.
At this point, when loading libphp5.so with apache gives a
number of unresolved references for iconv, xml, and mysql routines.

Now by modifying the Apache Makefile so that I include libxml2.la and
libiconv.la, the unresolveds are just for mysql. The MySQL package
I downloaded was precomiled for QNX and did not have .la files, so
I am looking into downloading and compiling these myself.

Of course, even then I don’t know if it will work. More later.

Finally I have it all working. Here is how I did it.

Note my previous comments about current version of autoconf, automake,
libtools, etc. In addition, I had to download the source to MySQL
version 5.0.24 In order to create it with a shared library
files libmysqlclient.la, and libz.la.

In my php development directory I created a Makefile2 described below
that is equivalent to Makefile’s creation of libphp5.la.
I then modified it to remove the -l, $(LIBS) references.
I’ve listed Makefile2 below, but I’ve left out the list of
objects because it is very long. After I create libphp5.la
using this Makefile, I run “make install” which now also works.

Makefile2:
OBJECTS =
…

INCLUDE = -I/usr/local/include
PATHS = -rpath /usr/util/php/php-5.1.4/libs
ARGS1 = --silent --preserve-dup-deps --mode=link gcc
ARGS2 = -g -O2 -avoid-version -module

LIBRARYS = -L/usr/local/lib -L/usr/local/mysql/lib -R /usr/local/lib -R /usr/local/mysql/lib

LIBRARYS2 = -R /usr/local/lib

LIBS =
-l mysqlclient -liconv -liconv -lm -lsocket -lxml2 -lz -lm
-lsocket -lxml2 -lz -lm -lsocket -lxml2 -lz -lm -lsocket
-lxml2 -lz -lm -lsocket -lxml2 -lz -lm -lsocket -lxml2
-lz -lm -lsocket

all: libphp5.la

#Original Version that won’t create a shared library
xlibphp5.la:
/bin/sh /usr/util/php/php-5.1.4/libtool $(ARGS1) $(INCLUDE)
$(PATHS) $(ARGS2) $(LIBRARYS) $(OBJECTS_EXT) $(OBJECTS_REGEX)
$(OBJECTS_TSRM) $(OBJECTS_MAIN) $(OBJECTS_ZEND) $(OBJECTS_SAPI)
$(LIBS) -o libphp5.la

#new version that will create a shared library
libphp5.la:
/bin/sh /usr/util/php/php-5.1.4/libtool $(ARGS1) $(INCLUDE)
$(PATHS) $(ARGS2) $(LIBRARYS2) $(OBJECTS_EXT) $(OBJECTS_REGEX)
$(OBJECTS_TSRM) $(OBJECTS_MAIN) $(OBJECTS_ZEND) $(OBJECTS_SAPI)
-o libphp5.la

Next, in the Apache version 2.0.54 development directory I
create another Makefile2 as follows:

Makefile2:
MODULES =
modules.lo
modules/aaa/mod_access.la
modules/aaa/mod_auth.la
modules/filters/mod_include.la
modules/loggers/mod_log_config.la
modules/metadata/mod_env.la
modules/metadata/mod_setenvif.la
modules/http/mod_http.la
modules/http/mod_mime.la
modules/generators/mod_status.la
modules/generators/mod_autoindex.la
modules/generators/mod_asis.la
modules/generators/mod_cgi.la
modules/mappers/mod_negotiation.la
modules/mappers/mod_dir.la
modules/mappers/mod_imap.la
modules/mappers/mod_actions.la
modules/mappers/mod_userdir.la
modules/mappers/mod_alias.la
modules/mappers/mod_so.la
server/mpm/prefork/libprefork.la
server/libmain.la
os/unix/libos.la
/usr/util/apache/httpd-2.0.54/srclib/pcre/libpcre.la
/usr/util/apache/httpd-2.0.54/srclib/apr-util/libaprutil-0.la

ARGS = --silent --mode=link gcc -g -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -export-dynamic

INCLUDES =
-I/usr/util/apache/httpd-2.0.54/srclib/apr/include
-I/usr/util/apache/httpd-2.0.54/srclib/apr-util/include
-I.
-I/usr/util/apache/httpd-2.0.54/os/unix
-I/usr/util/apache/httpd-2.0.54/server/mpm/prefork
-I/usr/util/apache/httpd-2.0.54/modules/http
-I/usr/util/apache/httpd-2.0.54/modules/filters
-I/usr/util/apache/httpd-2.0.54/modules/proxy
-I/usr/util/apache/httpd-2.0.54/include
-I/usr/util/apache/httpd-2.0.54/modules/generators
-I/usr/util/apache/httpd-2.0.54/modules/dav/main

LIBS = -lexpat /usr/util/apache/httpd-2.0.54/srclib/apr/libapr-0.la -lm -lsocket

LIBS2 = -lexpat /usr/util/apache/httpd-2.0.54/srclib/apr/libapr-0.la
-L/usr/local/lib/mysql -lmysqlclient -lz
-L/usr/local/lib -lsocket -liconv -lxml2 -lm

all: httpd

httpd:
/usr/util/apache/httpd-2.0.54/srclib/apr/libtool
$(ARGS) $(INCLUDES) $(MODULES) $(LIBS2) -o httpd

After doing the usual configure, make, make install, I delete httpd,
and remake using Makefile2. This forces the inclusion of
/usr/local/lib/libiconv.la
/usr/local/lib/libxml2.la
/usr/local/lib/mysql/libmysqlclient.la
/usr/local/lib/mysql/libz.la

into the Apache httpd module.
I then run “make install” and all seems well.
I tested Apache with a very simple script:

Which worked just as expected. I’m now quitting to go celebrate.
If anyone can suggest a more kosher way of dealing with this, I’m
more than willing to try. It does seem that libtools should not be
complaining the way it does about included libraries, but I’m just
a novice at it so what do I know?