libiconv on 10.0-RELEASE

nano nanotek at
Sat Feb 1 07:36:52 UTC 2014

On 1/02/2014 6:27 PM, Guido Falsi wrote:
> On 02/01/14 08:14, nano wrote:
>> On 1/02/2014 6:03 PM, Guido Falsi wrote:
>> Hi, Guido. Thanks for your response.
>> Not sure about this users particular situation, except that it appears
>> they are experiencing some problems compiling libiconv [0]. Another user
>> seems to be experiencing problems (re)installing php5x-iconv, which has
>> rendered something broken [1]. This makes me reluctant to proceed with
>> my upgrades for fear that similar will occur.
>> Also, I'm not usng svn, but portsnap; don't know if it matches r341775.
> Don't know at what time you ran portsnap, but, portsnap simply tracks
> the subversion repository, it's just a little lagged but just by one
> hour at most, so you most probably have a ports tree post r341775.

That's good to know. I thought the delay was greater than that.

>> I appreciate your advice, but I think I will wait before updating these
>> ports. Hopefully things get cleaned up a bit. I would not be happy if
>> something breaks.
> I understand. I still have not had a good look at r341775 and have only
> built ports affected by it in poudrirere, and using them as binary
> packages, which works fine.

I may create a jail to somewhat emulate my live environment and conduct 
a test run to see if any problems arise.

>> [0]
>> [1]
> I really don't know what's going on on these user's systems. The error
> logs they posted have to little backlog to have any idea about what's
> really causing the problem.
> For what' I've seen php53-iconv should work fine, but if it's vital to
> you, you should then wait a little. These problems require some time and
> trials to fix.
> Most of the time the problem are the ported software packaging systems
> which assume FreeBSD has no iconv implementation and expect to find
> libiconv, or are unable to cope with two iconv implementations being
> available at the same time. This requires coping with such problems one
> by one which requires a little time and can't be really managed by
> automated testing systems, since these problems show up only on live
> systems.

Thanks for the intel. I'm happy to wait, I understand these things take 
time. I'd rather play it safe than be sorry. The upgrade may succeed 
without a hitch, but, if not, I'd lose more time to fixing things than 
waiting in the first place, I suspect.

If I do recreate an environment to test, I will notify you of my 
results. Thanks again.


More information about the freebsd-ports mailing list