# FreeBSD 9.0 & PHP (5 - 5.5) iconv error



## andisian (Dec 27, 2012)

Anyone else experience iconv error 
	
	



```
please reinstall inconv library
```
 when running *./configure* for PHP in FreeBSD 9.0?

This FreeBSD install has been riddled with problems. The library is intact and available at DIR specified but it can't see it. Kind of leading to think it's an issue with the way the headers are being written like it*'*s ignoring my dir= switch when I run the config script, this happened also with xmlrpc, I disabled that in the configuration as a troubleshoot and ran into this error right after. 

Any suggestions or similar experiences?


----------



## SirDice (Dec 27, 2012)

Use the port lang/php5.

Handbook: Chapter 5 Installing Applications: Packages and Ports


----------



## andisian (Dec 28, 2012)

SirDice said:
			
		

> Use the port lang/php5.
> 
> Handbook: Chapter 5 Installing Applications: Packages and Ports


That is simply a workaround that does not address the issue, but instead goes a roundabout way to solving the problem. IMO that does not yield the best finished product. 

Obviously I can use ports/sysinstall if I want my PHP a la someone else. 

Mind you, if there is a bug I have no choice and that changes the landscape completely, but if there is something I can do to isolate the cause of said issue I can perhaps fix it and more importantly document the issue for the community at large. 

I'm old school- I should be able to compile manually into directories that I specify. I don't like auto anything. The ports are messy and distribute files all over with no cohesive similarities to other installations that have already taken place. As I rule I don't like my set ups to be structured any which way. I have not experienced this severity of issue with installing packages and I have been FreeBSD since ver. 4.11. 

Are we trying to collectively create a better product, or just jumping on the bok choy truck with a sys admin name tag? 

Any suggestions on how to execute this method or any similar issues with files/libs not being located by configure when they are exactly where they are supposed to be? Even a bunch of things I can check to help verify whether I have actually found a legitimate bug would be helpful at this point. 8.3 had no such issues with the same set up.

-AR

"In theory there is no difference between practice and theory, but in practice there is"


----------



## Rachel (Dec 28, 2012)

*Same problem*

I ran into the same problem, but I need to compile from source. I have no trouble on my 8.3 server, but this new 9.0 seems to have no end of issues.

Anyone know how to compile either php 5.3.20 or php 5.4.10, with any iconv, core, package, or source?

I can't use the php5 packages because I have in-house php modules written in c, and can only compile from source. My module isn't kicking up any errors,only iconv (which I need for xmlrpc)


----------



## kpa (Dec 28, 2012)

You could turn your in-house modules into your own private ports, use the existing php5 modules as template.


----------



## SirDice (Dec 28, 2012)

andisian said:
			
		

> As I rule I don't like my set ups to be structured any which way.


Seriously? You don't like structure? The guy that's going to replace you someday is going to have a really bad time :\

Using the ports is actually the most structured way of doing things. Contrary to what you may think files are definitely not placed "all over"; hier(7).


----------



## Rachel (Dec 28, 2012)

*Inconv "reinstall" error*

It does seem that my problem is the same as Andisian's. I'm not sure what his constraints are, but with my project we have a dev team that modifies source, I just compile and install. They, being programmers, have given up, and have let the senior sys arch deal with it, me.

I haven't ruled out an issue with the compiler in 9.0, or php or iconv themselves, though I've run into some shockingly poor thinking in this 9.0 distro. I've been building and supporting FreeBSD since 3.2, and this has definately been the most slapdash major release in my 15 years with FreeBSD specifically, and 20 years with BSD in general. Though, this isn't intended to be a flame post; sorry.

"Just use the package", really is a very Linux answer to a problem, and I would do it as this has taken up way too much of my time, but I simply do not have a choice. If I can't get PHP working in 9.0 with iconv by Jan. 2 I'll have to tell my director that we'll have to defer all 9.branch testing until 9.1 or 9.2, which is a terrible shame.

Has anyone seen this problem? If anyone has seen source compile issues with php on 9.0, and if they have actually figured it out, I'd love to hear about it. At least for a couple days I'll keep plugging away at it, and I'll share with Andisian if I get it.

"Just use the package", lol, that really is very Linux ;^)


----------



## SirDice (Dec 28, 2012)

I didn't say "use the package". I would never say that because the PHP package does NOT contain the Apache module. I said, "use the port". The port compiles, links and installs perfectly.

@Rachel: If your devs can deliver patches you can drop them in the files/ directory and they will be applied when you build the port.

Porter's Handbook: 4.4 Patching


----------



## kpa (Dec 28, 2012)

Does it occur to you that it might be you who need to revise your thinking how to solve problems and not try find an easy scapegoat everytime you come across a hurdle that seems impassable?

As far as the iconv problem goes, my bet is that the configure script is somehow ignoring /usr/local/include that is the standard ${LOCALBASE}/include location in FreeBSD. Are you using the default /usr/local PREFIX?

And yeah, nobody here proposed to use packages :stud


----------



## Rachel (Dec 28, 2012)

*Packages and Ports*

Sorry guys, I misread. I thought you said packages, not ports.

I'll try what's in ports. With the source from php I've put the libs in /usr/local/libs and the header files in /usr/local/include. I've added -I -L and -l to the configure script with the correct paths to try forcing it. No luck. Hopefully ports won't be hopeless.

I can't honestly imagine who you think I'm trying to scapegoat. I haven't figured out whether it's 9.0, php5.3.20 or php5.4.10, iconv, gcc, the source config, or what. I haven't specifically blamed any of them. I did say that this 9.0 is slapdash, but that's based on bsdconfig and pkpng not being finished, yet bsdinstall being used, and a couple of other minor mistakes in an obviously rushed release.

Is my thinking old school? Absolutely yes! Will I let someone else's thinking drive mine? Absolutely not! Some of us are sheep, and some not...

But, I do stand corrected for my misread. Thank you :^)


----------



## Rachel (Dec 28, 2012)

Oh, and my particular dev issue is that our developers are modifying some language semantics in the php core... Not my choice, I just build and run the production env.

I thought it was their monkeying that was the culprit, but when I tried installing both 5.3.20 and 5.4.10, the two tar balls they code against, I had the same issue. My first thought after that was that maybe someone didn't get the configure script just right, but it's identical in two versions, and I have no issue on my production 8.3 boxes.

I really am not against ditching 9.0, and waiting for 9.1 or .2. I did that with 4.0 and 5.0 because they were not perfect either.


----------



## kpa (Dec 28, 2012)

A bad choise of words by me.... :\

Anyway, if I were now in your place I would still try to use as much as possible of the existing ports(7) infrastructure. I can not imagine the changes you do to PHP and the modules are such that could not be handled by custom patches in the files subdirectory as SirDice suggested.

If you still get stuck try to provide as much information as possible. We can only make educated guesses of what is going wrong if there's no logfiles for example from the configure run.

Use pastebin or similar service to upload the larger log files.


----------



## Rachel (Dec 28, 2012)

Ya, I haven't really provided much of my efforts here, other than description. Hoenstly, I didn't even want to bug anyone here as I had no issues with any of the other source installs I do, it's just that everyone in the php camp either had no idea what I was talking about, or they said deeply helpful stuff like, 'well, it works fine on RH/F/CO/SuSE/Scripting Kiddie Linux.'

The config.log just stops dead right at the point where configure says to reinstall iconv. I am leaning toward something funky with configure, but I've been through it four times changing and hard coding shell vars, paths, and I've tried running it against the iconv in packages, the php5_iconv in packages, and two different iconv source tbz's.

It could be personal. I did curse a little when I saw that bsdconfig and pkgng wheren't there, yet someone had taken pkg_install out. BSD, I am sorry for disparaging your parentage.

I'm no fan of how our dev team works, but one must be a corporate cheerleader, ra, ra, ra...


----------



## andisian (Dec 28, 2012)

SirDice said:
			
		

> Seriously? You don't like structure? The guy that's going to replace you someday is going to have a really bad time :\
> 
> Using the ports is actually the most structured way of doing things. Contrary to what you may think files are definitely not placed "all over"; hier(7).



You might have misinterpreted my response. I said "I don't like them structured _any_ which way" meaning I want to define my directory structure with regards to my major apps & want to compile it all manually- The way I have been for years and years.

I prefer to build each major app into separate directories under usr/local due in part to network storage and to honour development strategies currently in place.

Also since I own the company I highly doubt I will be replaced by anyone who does not share my views on data structure. Also, I don't find your comment to be conducive to the problem at hand.

Regardless of my reasons or whether or not you agree with my methodology I should be able to do this very basic task the same way I have been until now. 

Anyone else like to share some creative thinking that may help us isolate the issue?


----------



## SirDice (Dec 28, 2012)

I would suggest you also look in the files/ directory of the port. There are quite a lot of patches there. They are needed to get PHP compiled on FreeBSD, I'm sure one of them addresses the issue you are having.


----------

