Jani,
What was the reasoning behind the 1.15->1.16 patch for phpize.in? Your
comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
This had an unfortunate effect of building shared extensions on Mac OS
X as .dylib shared libraries, instead of dlopen()'able bundles. The
bundled libtool is way old and does not handle this properly, while the
new ones do.
-Andrei
Also, you removed calls to aclocal which presents yet another problem.
My shared extension uses external aclocal macros and since aclocal is
not run, it cannot locate and bundle them into aclocal.m4. Please fix.
-Andrei
Jani,
What was the reasoning behind the 1.15->1.16 patch for phpize.in? Your
comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
This had an unfortunate effect of building shared extensions on Mac OS
X as .dylib shared libraries, instead of dlopen()'able bundles. The
bundled libtool is way old and does not handle this properly, while
the new ones do.
-Andrei
Care to elaborate a bit? Exactly WHAT macros you use?
--Jani
Also, you removed calls to aclocal which presents yet another problem. My
shared extension uses external aclocal macros and since aclocal is not run, it
cannot locate and bundle them into aclocal.m4. Please fix.-Andrei
Jani,
What was the reasoning behind the 1.15->1.16 patch for phpize.in? Your
comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
This had an unfortunate effect of building shared extensions on Mac OS X as
.dylib shared libraries, instead of dlopen()'able bundles. The bundled
libtool is way old and does not handle this properly, while the new ones do.-Andrei
PHP-GTK uses a lot of external macros though its extensions, such as
AM_PATH_GLIB_2_0(), AM_PATH_GTK_2_0(), and others. Those are contained
in .m4 files located in aclocal's share directory and without running
aclocal the configuration process fails, since those macros are
external.
-Andrei
Care to elaborate a bit? Exactly WHAT macros you use? --JaniAlso, you removed calls to aclocal which presents yet another
problem. My shared extension uses external aclocal macros and since
aclocal is not run, it cannot locate and bundle them into aclocal.m4.
Please fix.-Andrei
Jani,
What was the reasoning behind the 1.15->1.16 patch for phpize.in?
Your comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
This had an unfortunate effect of building shared extensions on Mac
OS X as .dylib shared libraries, instead of dlopen()'able bundles.
The bundled libtool is way old and does not handle this properly,
while the new ones do.-Andrei
Good enough explanation. Fixed in CVS.
--Jani
PHP-GTK uses a lot of external macros though its extensions, such as
AM_PATH_GLIB_2_0(), AM_PATH_GTK_2_0(), and others. Those are contained in .m4
files located in aclocal's share directory and without running aclocal the
configuration process fails, since those macros are external.-Andrei
Care to elaborate a bit? Exactly WHAT macros you use? --JaniAlso, you removed calls to aclocal which presents yet another problem. My
shared extension uses external aclocal macros and since aclocal is not run,
it cannot locate and bundle them into aclocal.m4. Please fix.-Andrei
Jani,
What was the reasoning behind the 1.15->1.16 patch for phpize.in? Your
comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
This had an unfortunate effect of building shared extensions on Mac OS X
as .dylib shared libraries, instead of dlopen()'able bundles. The bundled
libtool is way old and does not handle this properly, while the new ones
do.-Andrei
What was the reasoning behind the 1.15->1.16 patch for phpize.in? Your
comments say:
- Changed phpize not to require automake and libtool.
- Fixed build system to always use bundled libtool files.
a) To only require autoconf to be installed to be able to use phpize
b) Prevent problems with different libtool versions
This had an unfortunate effect of building shared extensions on Mac OS X as
.dylib shared libraries, instead of dlopen()'able bundles. The bundled libtool
is way old and does not handle this properly, while the new ones do.
Thus we'll nuke the libtool usage in linking on Macosx.
Patch to acinclude.m4 for this solution is here:
http://www.php.net/~jani/patches/acinclude.m4.macosx-shared-modules.patch
(or someone backports the patches from newer libtools to the
bundled files =)
Reason not to bundle newer libtool: It requires buggy autoconf 2.5x.
--Jani
Thus we'll nuke the libtool usage in linking on Macosx. Patch to acinclude.m4 for this solution is here:http://www.php.net/~jani/patches/acinclude.m4.macosx-shared-
modules.patch(or someone backports the patches from newer libtools to the bundled files =) Reason not to bundle newer libtool: It requires buggy autoconf2.5x.
Jani,
That patch worked great. Could you please commit it to the tree?
-Andrei
Thus we'll nuke the libtool usage in linking on Macosx. Patch to acinclude.m4 for this solution is here: http://www.php.net/~jani/patches/acinclude.m4.macosx-shared-modules.patch
(or someone backports the patches from newer libtools to the bundled files =) Reason not to bundle newer libtool: It requires buggy autoconf 2.5x.Jani,
That patch worked great. Could you please commit it to the tree?
I've done a little work on HEAD to make it require autoconf 2.59
and bundle libtool 1.5.10 so this patch might not be necessary there.
But as I don't know if anybody else wishes to start requiring newer
autoconf as of PHP 5.1.x, I'll just commit the patch.
--Jani
I've done a little work on HEAD to make it require autoconf 2.59 and bundle libtool 1.5.10 so this patch might not be necessary there. But as I don't know if anybody else wishes to start requiring newer autoconf as of PHP 5.1.x, I'll just commit the patch.
Still, I think making the linking independent of libtool might be a win
here, considering that there are potential conflicts between the bundled
libtool, and the couple of external ones that Mac OS X comes with.
- Andrei
I've done a little work on HEAD to make it require autoconf 2.59 and bundle libtool 1.5.10 so this patch might not be necessary there. But as I don't know if anybody else wishes to start requiring newer autoconf as of PHP 5.1.x, I'll just commit the patch.Still, I think making the linking independent of libtool might be a win
here, considering that there are potential conflicts between the bundled
libtool, and the couple of external ones that Mac OS X comes with.
We do link the binaries and libphp*.so without libtool so
why not the shared extensions too. :)
--Jani
We do link the binaries and libphp*.so without libtool so why not the shared extensions too. :)
Exactly. Can we do that or is that already done? :)
- Andrei
We do link the binaries and libphp*.so without libtool so why not the shared extensions too. :)Exactly. Can we do that or is that already done? :)
Already done.
--Jani
Andrei Zmievski wrote:
Thus we'll nuke the libtool usage in linking on Macosx. Patch to acinclude.m4 for this solution is here: http://www.php.net/~jani/patches/acinclude.m4.macosx-shared-modules.patch
(or someone backports the patches from newer libtools to the bundled files =) Reason not to bundle newer libtool: It requires buggy autoconf 2.5x.Jani,
That patch worked great. Could you please commit it to the tree?
-Andrei
Jani, buildconf on fbsd appears unhappy now.
2:09pm riddler:~/php43> ./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.59 (ok)
buildconf: running cvsclean.
"build/build2.mk", line 35: Missing dependency operator
"build/build2.mk", line 37: Need an operator
"build/build2.mk", line 39: Need an operator
make: fatal errors encountered -- cannot continue
I don't think BSD make can handle that ifeq there. Setting the MAKE env
to gmake makes it work.
-Rasmus
The new bundled libtool seems unhappy on fbsd as well. Trying
--with-gd=shared gives me:
/bin/bash /homes/rasmus/php43/libtool --silent --preserve-dup-deps
--mode=link gcc -DPHP_ATOM_INC -I/homes/rasmus/php43/include
-I/homes/rasmus/php43/main -I/homes/rasmus/php43
-I/homes/rasmus/php43/Zend -I/usr/local/include
-I/usr/local/include/freetype2 -I/homes/rasmus/php43/TSRM
-DSKIP_PATH_CHECKS -g -O2 -Wall -L/home/y/lib -o ext/gd/gd.la
-export-dynamic -avoid-version -prefer-pic -module -rpath
/homes/rasmus/php43/modules -avoid-version -module -L/lib ext/gd/gd.lo
ext/gd/gdttf.lo ext/gd/libgd/gd.lo ext/gd/libgd/gd_gd.lo
ext/gd/libgd/gd_gd2.lo ext/gd/libgd/gd_io.lo ext/gd/libgd/gd_io_dp.lo
ext/gd/libgd/gd_io_file.lo ext/gd/libgd/gd_ss.lo
ext/gd/libgd/gd_io_ss.lo ext/gd/libgd/gd_png.lo ext/gd/libgd/gd_jpeg.lo
ext/gd/libgd/gdxpm.lo ext/gd/libgd/gdfontt.lo ext/gd/libgd/gdfonts.lo
ext/gd/libgd/gdfontmb.lo ext/gd/libgd/gdfontl.lo ext/gd/libgd/gdfontg.lo
ext/gd/libgd/gdtables.lo ext/gd/libgd/gdft.lo ext/gd/libgd/gdcache.lo
ext/gd/libgd/gdkanji.lo ext/gd/libgd/wbmp.lo ext/gd/libgd/gd_wbmp.lo
ext/gd/libgd/gdhelpers.lo ext/gd/libgd/gd_topal.lo
ext/gd/libgd/gd_gif_in.lo ext/gd/libgd/xbm.lo ext/gd/libgd/gd_gif_out.lo
-R/usr/local/lib -L/usr/local/lib -lfreetype -R/usr/local/lib
-L/usr/local/lib -lpng -lz -R/usr/local/lib -L/usr/local/lib -ljpeg
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
creating reloadable object files...
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
/homes/rasmus/php43/libtool: test: : integer expression expected
creating a temporary reloadable object file: ext/gd/.libs/ext/gd/gd.la-29.o
/usr/libexec/elf/ld: cannot open output file
ext/gd/.libs/ext/gd/gd.la-1.o: No such file or directory
gmake: *** [ext/gd/gd.la] Error 1
Replacing ./libtool with my /usr/local/bin/libtool makes it work.
A diff -u of the two libtool scripts is here:
http://lerdorf.com/libtool.diff
-Rasmus