On Dec 7, 2007, at 10:10 , Fabian Groffen wrote:


On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:

Long story short:


A longer version:

libiconv now has been "fixed" to always have the same declaration in
Prefix, regardless the host OS declaration. I don't know why one
would

like to have that, most programs with decent autoconf have checks for
that anyway. Anyhow, you should update libiconv first, then
compilation

of doxygen should succeed. I tested this on Solaris 10, OS X 10.4 and
OS X 10.5.


Seing that these are all pretty live events, I may be slightly out of
sync here. But I just upgraded libiconv and experienced massive
breakage due to symlinks missing in usr/lib.


// Johan

--
gentoo-alt@gentoo.org mailing list

On 07-12-2007 10:13:30 +0100, Johan Hattne wrote:
>
> On Dec 7, 2007, at 10:10 , Fabian Groffen wrote:
>
>> On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:
>>> Long story short:
>>
>> A longer version:
>>
>> libiconv now has been "fixed" to always have the same declaration in
>> Prefix, regardless the host OS declaration. I don't know why one would
>> like to have that, most programs with decent autoconf have checks for
>> that anyway. Anyhow, you should update libiconv first, then compilation
>> of doxygen should succeed. I tested this on Solaris 10, OS X 10.4 and
>> OS X 10.5.
>
> Seing that these are all pretty live events, I may be slightly out of sync
> here. But I just upgraded libiconv and experienced massive breakage due to
> symlinks missing in usr/lib.

Eh... nothing should have changed there... Can it be that you're caught
by an old "pre-put-the-libs-in-the-right-place" installation?

P.S. you can "remedy" some vital components with install_name_tool.
Make sure you reinstall stuff though. Best thing to do is to
rebootstrap... sorry.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

On Dec 7, 2007, at 10:18 , Fabian Groffen wrote:


On 07-12-2007 10:13:30 +0100, Johan Hattne wrote:


On Dec 7, 2007, at 10:10 , Fabian Groffen wrote:


On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:

Long story short:


A longer version:

libiconv now has been "fixed" to always have the same declaration in
Prefix, regardless the host OS declaration. I don't know why one
would
like to have that, most programs with decent autoconf have checks
for
that anyway. Anyhow, you should update libiconv first, then
compilation
of doxygen should succeed. I tested this on Solaris 10, OS X
10.4 and

OS X 10.5.


Seing that these are all pretty live events, I may be slightly out
of sync
here. But I just upgraded libiconv and experienced massive
breakage due to

symlinks missing in usr/lib.


Eh... nothing should have changed there... Can it be that you're
caught

by an old "pre-put-the-libs-in-the-right-place" installation?


Yes, that'd be it. I haven't bootstrapped since I first installed
this instance (January 2007?).


Sorry for the noise, and apologies for accidentally sending the
previous message twice.



P.S. you can "remedy" some vital components with install_name_tool.
Make sure you reinstall stuff though. Best thing to do is to
rebootstrap... sorry.


OK, will try to fix. I guess the fact that strlen("usr/lib") < strlen
("lib") will be real handy when doing the install_name_tool trick.


// Johan

--
gentoo-alt@gentoo.org mailing list

On 07-12-2007 10:24:49 +0100, Johan Hattne wrote:
>> Eh... nothing should have changed there... Can it be that you're caught
>> by an old "pre-put-the-libs-in-the-right-place" installation?
>
> Yes, that'd be it. I haven't bootstrapped since I first installed this
> instance (January 2007?).

Ok, then that's the issue

> Sorry for the noise, and apologies for accidentally sending the previous
> message twice.
>
>> P.S. you can "remedy" some vital components with install_name_tool.
>> Make sure you reinstall stuff though. Best thing to do is to
>> rebootstrap... sorry.
>
> OK, will try to fix. I guess the fact that strlen("usr/lib") <
> strlen("lib") will be real handy when doing the install_name_tool trick.

install_name_tool is quite nice, as it can also do the other way around.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

On Dec 7, 2007, at 10:26 , Fabian Groffen wrote:


P.S. you can "remedy" some vital components with install_name_tool.
Make sure you reinstall stuff though. Best thing to do is to
rebootstrap... sorry.


OK, will try to fix. I guess the fact that strlen("usr/lib") <
strlen("lib") will be real handy when doing the install_name_tool
trick.


install_name_tool is quite nice, as it can also do the other way
around.


It is nice, but doing it manually was fun only for the first couple
of binaries. I just realised that on darwin, one could get out of
this sort of mess by setting up DYLD_FALLBACK_LIBRARY_PATH
appropriately, and then reemerging whatever is broken. So I've set
aforementioned variable to ${EPREFIX}/lib, and am now in the process
of doing an emerge --emptytree world.


Thanks for your help!

// Johan

--
gentoo-alt@gentoo.org mailing list

On 07-12-2007 11:45:34 +0100, Johan Hattne wrote:
>
> On Dec 7, 2007, at 10:26 , Fabian Groffen wrote:
>
>>>> P.S. you can "remedy" some vital components with install_name_tool.
>>>> Make sure you reinstall stuff though. Best thing to do is to
>>>> rebootstrap... sorry.
>>>
>>> OK, will try to fix. I guess the fact that strlen("usr/lib") <
>>> strlen("lib") will be real handy when doing the install_name_tool trick.
>>
>> install_name_tool is quite nice, as it can also do the other way around.
>
> It is nice, but doing it manually was fun only for the first couple of
> binaries. I just realised that on darwin, one could get out of this sort
> of mess by setting up DYLD_FALLBACK_LIBRARY_PATH appropriately, and then
> reemerging whatever is broken. So I've set aforementioned variable to
> ${EPREFIX}/lib, and am now in the process of doing an emerge --emptytree
> world.

Make sure that "system" is present in your world set! Last time I
bootstrapped (yesterday) Portage magically added system by itself to
world, but it may not have done this for you yet.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

On Dec 7, 2007, at 11:48 , Fabian Groffen wrote:


On 07-12-2007 11:45:34 +0100, Johan Hattne wrote:

It is nice, but doing it manually was fun only for the first
couple of
binaries. I just realised that on darwin, one could get out of
this sort
of mess by setting up DYLD_FALLBACK_LIBRARY_PATH appropriately,
and then
reemerging whatever is broken. So I've set aforementioned
variable to
${EPREFIX}/lib, and am now in the process of doing an emerge --
emptytree

world.


Make sure that "system" is present in your world set! Last time I
bootstrapped (yesterday) Portage magically added system by itself to
world, but it may not have done this for you yet.


Gaah! It isn't!

OK, so emerge --emptytree system first.

// Johan

--
gentoo-alt@gentoo.org mailing list

On 07-12-2007 10:10:44 +0100, Fabian Groffen wrote:
> On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:
> > Long story short:
>
> A longer version:
>
> libiconv now has been "fixed" to always have the same declaration in
> Prefix, regardless the host OS declaration. I don't know why one would
> like to have that, most programs with decent autoconf have checks for
> that anyway. Anyhow, you should update libiconv first, then compilation
> of doxygen should succeed. I tested this on Solaris 10, OS X 10.4 and
> OS X 10.5.

Tested on FreeBSD 6.2 too.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

On Dec 7, 2007, at 14:36 , Fabian Groffen wrote:


On 07-12-2007 10:10:44 +0100, Fabian Groffen wrote:

On 06-12-2007 22:31:02 +0100, Fabian Groffen wrote:

Long story short:


A longer version:

libiconv now has been "fixed" to always have the same declaration in
Prefix, regardless the host OS declaration. I don't know why one
would

like to have that, most programs with decent autoconf have checks for
that anyway. Anyhow, you should update libiconv first, then
compilation
of doxygen should succeed. I tested this on Solaris 10, OS X 10.4
and

OS X 10.5.


Tested on FreeBSD 6.2 too.


But shouldn't doxygen have a dependence on libiconv? Otherwise, how
can one prevent it from linking to libiconv outside prefix?


// Cheers; Johan

--
gentoo-alt@gentoo.org mailing list

On 12-12-2007 11:54:50 +0100, Johan Hattne wrote:
[...]
> But shouldn't doxygen have a dependence on libiconv? Otherwise, how can
> one prevent it from linking to libiconv outside prefix?

http://bugs.gentoo.org/show_bug.cgi?id=202027


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list