|
Mitchell Schoenbrun
10/13/2007 2:24 PM
post1997
|
Well I spoke too soon when I said Apache22/PHP5 were working. I was able to complete the builds, and it looked really
good until I actually tried to run Apache. In the step where mod_php5.so, really libphp5.so was loaded, apache
reported that the file was not there, and a little further on it crashed.
I did extensive verification to make sure that libphp5.so was there, and was readable, so that is not the problem.
I've decided to go back and play by the rules in case my idea of deleting .wrapper/bin/cc may have caused this behavior.
I found the step where the -R/usr/pkg/lib caused the compiler to fail, and I've recreated it carefully. I'm hoping
to hold the developers of .wrapper/bin/cc to their statement that "It supports the -R option".
Here is the command that configure trys to execute:
/usr/pkgsrc/lang/php5/work/.wrapper/bin/cc -o conftest -O2 -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -R/
usr/pkg/lib -L/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -R/usr/pkg/lib -L/usr/pkg/lib conftest.c -
lcrypto -lm -lsocket -lxml2 -lz -liconv -lm -lsocket
I'm attaching a file 'result' which is the output of running this command in verbose mode. If you look carefully a
few lines from the bottom, you will see that qcc is being given the -R option, and it does not like it.
|
|
|
|
|
|
Mitchell Schoenbrun
10/15/2007 12:52 PM
post2008
|
Well my attempt to let .wrapper/bin/cc do it's job was not very productive. I manually patched configure so that it
would ignore the compiler failures due to the -R option. When the compiling started a big problem was that between
libtool and .wrapper/bin/cc, libraries were not being found. I could run the compile steps without .wrapper/bin/cc
manually to I continued further. In the final step where libphp5.so was supposed to be created, it was not. Instead
I think libtools decided to make the static libphp5.a only. This of course defeats the purpose, since Apache does not
have anything to load.
Outside of pkgsrc, I was able to build apache 2.0 a while ago, but it was not straightforward either. At that time,
libtools did not like having shared objects call routines in shared objects. I had to force a number of modules to be
included in libphp5.so, and later, in apached itself, but in the end it worked.
This suggests that there is a solution, but I'm not sure where to proceed. Right now the weak point seems to be the .
wrapper/bin/* files, and I can't even figure out how they work.
Any suggestions?
|
|
|
|
|
|
Christian Leutloff
10/15/2007 2:13 PM
post2012
|
Perhaps our problems with dynamic libs for php5 and python24 are related!?
I know that it is not possible to use normal static libs to build a dynamic module, e.g. if you want to link libsocket
statically you must use libsocketS.a instead of libsocket.a to link it to your .so module. Therefore if try to
statically link the libs you may want to ensure that the included libs ends with S.
Some other ideas:
a) Can you extract the shell commands to build libphp5.so (to execute it on the command line and/or to post it here)!?
b) Have you tried to look at the libphp5.so with ldd?
Here is an example from QNX photon. It is an example where one so loads another one:
$ cd /usr/photon/bin
$ ldd fontadmin
./fontadmin:
libfontharnessutils.so.1 => /lib/libfontharnessutils.so.1 (0xb8200000)
libfont.so.1 => /lib/libfont.so.1 (0xb8205000)
libAp.so.3 => /usr/lib/libAp.so.3 (0xb8210000)
libph.so.3 => /usr/lib/libph.so.3 (0xb8220000)
libphrender.so.2 => /usr/lib/libphrender.so.2 (0xb8320000)
libm.so.2 => /lib/libm.so.2 (0xb8355000)
libc.so.2 => /usr/lib/ldqnx.so.2 (0xb0300000)
$ ldd /usr/lib/libph.so.3
/usr/lib/libph.so.3:
libph.so.3 => /usr/lib/libph.so.3 (0xb8200000)
libfont.so.1 => /lib/libfont.so.1 (0xb8300000)
Under Linux you get the following for the php module (I suppose that this will look very similar for QNX):
$ ldd /usr/lib/apache2/modules/libphp5.so
linux-gate.so.1 => (0xffffe000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7a49000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7a34000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb79f2000)
libdb-4.5.so => /usr/lib/libdb-4.5.so (0xb78d5000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb78c5000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb789f000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb788c000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7867000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7862000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb784a000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7821000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7799000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7774000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7771000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7652000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7508000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb73c5000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb73ad000)
/lib/ld-linux.so.2 (0x80000000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb73a5000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb73a2000)
|
|
|
|
|
|
Mitchell Schoenbrun
10/15/2007 6:09 PM
post2013
|
> Perhaps our problems with dynamic libs for php5 and python24 are related!?
I think this is very likely.
> I know that it is not possible to use normal static libs to build a dynamic
> module, e.g. if you want to link libsocket statically you must use libsocketS.
> a instead of libsocket.a to link it to your .so module. Therefore if try to
> statically link the libs you may want to ensure that the included libs ends
> with S.
As far as I can tell, the scripts are attempting to build with dynamic libraries only.
> a) Can you extract the shell commands to build libphp5.so (to execute it on
> the command line and/or to post it here)!?
Here is one example:
/bin/sh /usr/pkgsrc/lang/php5/work/php-5.2.4/libtool --silent --preserve-dup-deps --mode=compile cc -Imain/ -I/usr/
pkgsrc/lang/php5/work/php-5.2.4/main/ -DPHP_ATOM_INC -I/usr/pkgsrc/lang/php5/work/php-5.2.4/include -I/usr/pkgsrc/lang/
php5/work/php-5.2.4/main -I/usr/pkgsrc/lang/php5/work/php-5.2.4 -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/
pkgsrc/lang/php5/work/php-5.2.4/ext/date/lib -I/usr/local/include/mysql -I/usr/pkg/include/mysql -I/usr/pkgsrc/lang/php5
/work/php-5.2.4/TSRM -I/usr/pkgsrc/lang/php5/work/php-5.2.4/Zend -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/
include -O2 -I/usr/pkg/include -c main/internal_functions_cli.c -o main/internal_functions_cli.lo
>
> b) Have you tried to look at the libphp5.so with ldd?
>
Currently, compiling with .wrapper/bin/cc libphp5.so is not created.
With my first attempt I erased .wrapper/bin/cc and was able to create libphp5.so, which did not work propery with Apache
. I'm making the assumption that this attempt is worthless. If you think it might be valuable to see what it looked
like, I can recreate it and see.
Thank you for the advice.
|
|
|
|
|
|
Christian Leutloff
10/16/2007 2:38 PM
post2036
|
I'm now relative sure that our problems with the dynamic libs can be solved in a similar manner. Therefore I've looked
at php5, too. But it fails during the configuration step as you have reported with:
cc: unknown option: '-R/usr/pkg/lib'
I've done some more investigations about the dynamic lib problem and provided them in "my" task about python.
|
|
|
|
|
|
Mitchell Schoenbrun
10/16/2007 6:14 PM
post2044
|
> I'm now relative sure that our problems with the dynamic libs can be solved in
> a similar manner. Therefore I've looked at php5, too. But it fails during the
> configuration step as you have reported with:
>
> cc: unknown option: '-R/usr/pkg/lib'
>
Yes I'm quite sure they are similar. You get the unknown option because previous to this error around line 3100 the
script decides that
-R is supported. I was informed that his is correct behavior because .wrapper/bin/cc does support -R. I don't know
why the wrappers end up calling qcc later with the -R option, that hasn't
been explained to me yet.
If you change the script so that it does not think -R is supported, then you get an almost endless set of libraries not
found errors.
An alternative is to just delete the cc wrapper. This allows the build, but the resulting shared object libphp5.so
which is needed to run with
apache is defective.
I will keep an eye on your progress. I am unable to continue with php5 for a week or so, but I will get back to it.
I have my own self
interest to keep me dedicated.
|
|
|
|
|
|
Mitchell Schoenbrun
04/02/2008 2:59 AM
post6363
|
I've just picked up this thread again because it seems the right place. The last post was 6 months ago, and back then
I reported the problem with the cc wrapper. Now that I've picked things up to try again, I'm sad to see that it has
not changed at all. Can someone comment on this?
|
|
|
|
|
|
Sean Boudreau(deleted)
04/02/2008 8:26 AM
post6376
|
On Wed, Apr 02, 2008 at 02:59:27AM -0400, Mitchell Schoenbrun wrote:
> I've just picked up this thread again because it seems the right place. The last post was 6 months ago, and back
then I reported the problem with the cc wrapper. Now that I've picked things up to try again, I'm sad to see that it
has not changed at all. Can someone comment on this?
Try commenting out the 'PKGSRC_COMPILER=qcc' line from your
/usr/pkg/etc/mk.conf for this particular package. I think
using gcc directly is where we'll move eventually due to
these sorts of issues...
-seanb
|
|
|
|
|
|
Mitchell Schoenbrun
04/02/2008 12:46 PM
post6382
|
> Try commenting out the 'PKGSRC_COMPILER=qcc' line from your
> /usr/pkg/etc/mk.conf for this particular package. I think
> using gcc directly is where we'll move eventually due to
> these sorts of issues...
Ah, this did not work, but it makes sense why. The software that has a problem with the -R option is gcc. I'm
guessing that the next move is to upgrade gcc? If so, do I do that with pkgsrc, or is there a downloadable binary?
|
|
|
|
|
|
Rennie Allen
04/02/2008 12:51 PM
post6383
|
> Ah, this did not work, but it makes sense why. The software that has a
> problem with the -R option is gcc. I'm guessing that the next move is to
> upgrade gcc? If so, do I do that with pkgsrc, or is there a downloadable
> binary?
Did you run xiaodan's script to make gcc 3.3.5 the default? I modified it to make 4.2.1 the default myself...
|
|
|
|
|
|
Mitchell Schoenbrun
04/02/2008 1:22 PM
post6385
|
> Did you run xiaodan's script to make gcc 3.3.5 the default?
I did it a long time ago manually.
I modified it to
> make 4.2.1 the default myself...
I'd be happy to try 4.2.1. Can you tell me how to obtain it?
|
|
|
|
|
|
Sean Boudreau(deleted)
04/02/2008 1:26 PM
post6386
|
On Wed, Apr 02, 2008 at 01:22:38PM -0400, Mitchell Schoenbrun wrote:
>
> > Did you run xiaodan's script to make gcc 3.3.5 the default?
>
> I did it a long time ago manually.
>
>
> I modified it to
> > make 4.2.1 the default myself...
>
> I'd be happy to try 4.2.1. Can you tell me how to obtain it?
>
There's an archive in the tools project. Last I checked though
it had a few issues (no gcc, g++ drivers; c++ issues).
I have php5 built in my frankenstein environment. Want a binary
package?
-seanb
|
|
|
|
|
|
Rennie Allen
04/02/2008 1:38 PM
post6387
|
> I have php5 built in my frankenstein environment. Want a binary
> package?
I would prefer the diff:
diff checked-in-version frankenstein-version :-)
|
|
|
|
|
|
Mitchell Schoenbrun
04/02/2008 1:43 PM
post6388
|
> I have php5 built in my frankenstein environment. Want a binary
> package?
Thank you, but I'm rather sure it would not help. I've been using PHP5 under Apache2 for a while, and periodically I
find that there's some new feature that I'm missing that I have to recompile for. This was very tricky as I had to
statically link in modules to Apache for php5 because of linker problems. I limped along this way for a while doing
this until pkgsrc came around. Then I removed all the misc. pkgs I had downloaded myself to start over. While I'm
not under any time pressure, I'm pretty messed up now, not being able to reconfigure. I have a working version on-line
.
The 2nd reason I doubt your version would work has to do with why the -R is coming up at all. I believe it has
something to do with building shared libraries. What I really need for Apache2 is a shared library called mod_php5.so.
The last time I slogged through the pkgsrc compile, I ended up as before, with an unusable module. I think the
error I got is still listed in this thread so I won't repeat it.
I realize that I'm moving along a path that will not directly benefit QNX 6 users very much, as few of them will want to
repeat what I'm doing, but I think that getting these bugs out of pkgsrc can't but help.
|
|
|
|
|
|
Mitchell Schoenbrun
04/02/2008 4:52 PM
post6398
|
I don't want to sound exasperated, which is my current state, but....
I just discovered another problem with .wrapper/bin/gcc, as well as qcc and cc. I have a perfectly good command line
which finds, in this case /usr/pkg/lib/libpng.a, but when run through one of these wrappers, it no longer finds it. So
right now, these wrappers are getting in the way
|
|
|
|
|
|
ingo baab
10/21/2008 6:38 AM
post15306
|
Hi seanb,
I want a binary package :-) Can you provide me with it? ibaab-at-harmabecker-dot-com?
Best Regards,
-Ingo
|
|
|
|
|
|
Mitchell Schoenbrun
10/21/2008 11:28 AM
post15340
|
There's a catch with any binary package, does it have the features that you want? The range of options that can be put
into PHP5 is large. If you want a copy of my compiled sources let me know at maschoen@pobox.com.
|
|
|
|
|
|
