macOS PHP wont build on Lion

[rich06]

Hope someone can help me here as I am really stuck and am getting desperate to resolve this problem!

I am running OS X 10.7.2 Lion on my MBP and I need to build my own version of PHP rather than use the pre-installed version from Apple which has several shortcomings for my purposes. I downloaded v5.3.8 of PHP and the 'make' keeps on failing with these (or very similar errors):-

Undefined symbols for architecture x86_64:
  "_libiconv_open", referenced from:
      _do_convert in gdkanji.o
      _convert in encodings.o
  "_libiconv", referenced from:
      _do_convert in gdkanji.o
      _convert in encodings.o
  "_libiconv_close", referenced from:
      _do_convert in gdkanji.o
      _convert in encodings.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1

Having googled there were some fixes described (editing iconv.c, editing the Makefile, adding extra CFLAGS) ... I tried them all and nothing worked I have raised a bug on the PHP bug reporting site but they are ignoring/unresponsive regarding my bug report -> see here for more info https://bugs.php.net/bug.php?id=60268

Here's hoping someone here can help!
TIA!

 

[wrldwzrd89]

I had a similar odd problem building something else - x86-64 build was repeatedly failing in the same spot. Forcing the build architecture as x86 fixed it. Maybe give that a try?

 

[robvas]

Try this before building PHP:

export CC=/usr/bin/gcc-4.2

You have to do the that with Ruby because OS X Lion uses llvm for the compiler and not GCC. Not sure if that will help you but it's worth a shot.

Edit: Actually, looking at your error again I don't think that's your problem.

 

[jazzbo]

Looking at your bug report it looks like when you configuring the compile you're giving the following argument:

--with-iconv-dir=/opt/local

The errors are with the iconv libraries, so the question is: did you compile iconv (for the x86_64 arch) in /opt/local?

 

[rich06]

[RESOLVED] PHP wont build on Lion

Looking at your bug report it looks like when you configuring the compile you're giving the following argument:

--with-iconv-dir=/opt/local

The errors are with the iconv libraries, so the question is: did you compile iconv (for the x86_64 arch) in /opt/local?

Yes it was:- see below

[rich@eaurouge] (/opt/local/lib)> lipo -info libiconv.a
input file libiconv.a is not a fat file
Non-fat file: libiconv.a is architecture: x86_64
[rich@eaurouge] (/opt/local/lib)> file libiconv.2.dylib
libiconv.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64
[rich@eaurouge] (/opt/local/lib)>

However this afternoon I had another crack at getting it to work so I removed the PHP source code directory, re-installed the PHP 5.3.8 source ran configure and noticed this in the resultant Makefile:-

MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd [FONT="Arial Black"]-L/usr/lib[/FONT] -laprutil-1 -lldap -llber -llber -lexpat [FONT="Arial Black"]-liconv[/FONT] -L/usr/lib -lpq -lsqlite3 -lldap -llber -llber -L/usr/lib -lapr-1 -lpthread

So editing that line to:-

MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd [FONT="Arial Black"]-L/opt/local/lib[/FONT] -laprutil-1 -lldap -llber -llber -lexpat [FONT="Arial Black"]-liconv[/FONT] -L/usr/lib -lpq -lsqlite3 -lldap -llber -llber -L/usr/lib -lapr-1 -lpthread

Made it all work! Other solutions I had found out there in googleland just advised moving the complete MH_BUNDLE_FLAGS macro to the end of the compile directive - this didn't work because it was still going to look for libiconv in /usr/lib...

Anyway many thanks to all who responded - I'll update the PHP bug report in case this fix can help others pulling their hair out over this issue.

 

[Madd the Sane]

Wirelessly posted (Mozilla/5.0 (iPod; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)

It's worth noting that Apple does supply a version of iconv. Like all of Apple's supplied libraries and frameworks, it is a 32-bit 64-bit universal library. I don't know how it compares to other implementations of iconv, but it's there.

 

[rich06]

Wirelessly posted (Mozilla/5.0 (iPod; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)

It's worth noting that Apple does supply a version of iconv. Like all of Apple's supplied libraries and frameworks, it is a 32-bit 64-bit universal library. I don't know how it compares to other implementations of iconv, but it's there.

I presume that the Apple version is the one in /usr/lib? Well for some reason it has missing symbols compared to the version I got from Macports for the X86_64 architecture...

 

[Madd the Sane]

Actually, I think the /opt/local build headers of iconv added the prefix lib to some functions, because /usr/lib/libiconv.dylib doesn't have libiconv_open, but it does have iconv_open

 

[chown33]

Well for some reason it has missing symbols compared to the version I got from Macports for the X86_64 architecture...

What symbols are missing?

If the problem is only the "lib" prefix, easy to fix:

#define libiconv_open iconv_open
#define libiconv iconv
#define libiconv_close iconv_close

I assume you know enough C to figure out where to put those.

 

[rich06]

What symbols are missing?

If the problem is only the "lib" prefix, easy to fix:

#define libiconv_open iconv_open
#define libiconv iconv
#define libiconv_close iconv_close

I assume you know enough C to figure out where to put those.

Yea - I edited iconv.c along those lines -- it still failed to make tho'

 

[chown33]

Yea - I edited iconv.c along those lines -- it still failed to make tho'

If you're going to post "It failed", it's best to post the error messages of the failure. So we don't have to keep asking "Post the actual error messages".

 

[rich06]

If you're going to post "It failed", it's best to post the error messages of the failure. So we don't have to keep asking "Post the actual error messages".

Er.. actually I did post the make failure messages in my original post ...

BTW if you hadn't noticed this issue is resolved anyway - see my other earlier post above so I guess it is 'move along folks nothing to see here anymore...'

 

[chown33]

It wasn't clear that you were talking about the original failure.