| Author |
Message |
|
|
Post subject: Dependency Hell
 Posted: Aug 12, 2006 - 03:41 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
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. |
|
|
| |
|
|
|
 |
|
|
|
Post subject: RE: Dependency Hell
Posted: Aug 13, 2006 - 06:39 PM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
Have you looked at the QOpenCD project http://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. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Dependency Hell
Posted: Aug 14, 2006 - 04:44 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
Noc,
No I didn't know about this project. Thanks so much, I'll check it out.
Mitchell |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Dependency Hell
Posted: Aug 24, 2006 - 06:26 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
|
noc wrote:
Have you looked at the QOpenCD project http://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.
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Dependency Hell
Posted: Aug 24, 2006 - 08:52 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Post subject: Repost:
Posted: Aug 24, 2006 - 08:54 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
|
Code:
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] |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Repost:
Posted: Aug 24, 2006 - 10:48 PM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
|
Quote:
...
cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a
...
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". |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Repost:
Posted: Aug 25, 2006 - 04:39 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
|
noc wrote:
Quote:
...
cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a
...
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' |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Repost:
Posted: Aug 25, 2006 - 04:40 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
| One more minor point, the configure script says YES to shared libs, and NO to static ones. Go figure? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 25, 2006 - 05:14 AM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
.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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 25, 2006 - 06:41 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
|
noc wrote:
.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.
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.
Quote:
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":
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 25, 2006 - 04:45 PM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
|
|
|
|
|
|
|
Post subject:
Posted: Aug 26, 2006 - 02:17 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
|
noc wrote:
As I mentioned in below post
http://www.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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 26, 2006 - 02:40 AM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 974
|
|
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? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 26, 2006 - 05:49 AM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
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. |
|
|
| |
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
