On Thu, Mar 27, 2008 at 06:57:00PM +0100, Fabian Groffen wrote:

> > The cause seems obvious: If some package doesn't add
> > -I${EPREFIX}/usr/include and -L${EPREFIX}/usr/lib to its CFLAGS and
> > LDFLAGS, it will link against the system's libiconv. If this package
> > happens to be a library like glib, it pulls it into all the binaries
> > that link against it.

> This is exactly the reason we are using wrappers that inject those
> flags. If gcc and ld aren't first in your default search-path, things
> will get difficult.

Where would I find those wrappers? Because I've just emerge'd glib after
changing into prefix using startprefix which gave me this path:

PATH="/usr/local/gentoo/usr/sbin:/usr/local/gentoo/usr/bin:/usr/local/gentoo/sbin:/usr/local/gentoo/bin:/usr/local/gentoo/opt/bin:/usr/local/gentoo/usr/i686-apple-darwin9/binutils-bin/20080215:/usr/local/gentoo/usr/i686-apple-darwin9/gcc-bin/4.0.1:/usr/sbin:/usr/bin:/sbin:/bin"

and those binaries:

root@esgaroth:/usr/local/gentoo/usr/bin $ which gcc
/usr/local/gentoo/usr/bin/gcc
root@esgaroth:/usr/local/gentoo/usr/bin $ which i686-apple-darwin9-gcc
/usr/local/gentoo/usr/bin/i686-apple-darwin9-gcc
root@esgaroth:/usr/local/gentoo/usr/bin $ which ld
/usr/local/gentoo/usr/bin/ld

and I still get:

michael@esgaroth:~ # otool -L /usr/local/gentoo/usr/lib/libglib-2.0.dylib
/usr/local/gentoo/usr/lib/libglib-2.0.dylib:
/usr/local/gentoo/usr/lib/libglib-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/gentoo/usr/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.1.0)
/usr/local/gentoo/usr/lib/gcc/i686-apple-darwin9/4.0.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
--
bye,
Micha
--
gentoo-alt@lists.gentoo.org mailing list

On 27-03-2008 19:41:54 +0100, Michael Weiser wrote:
> Where would I find those wrappers? Because I've just emerge'd glib after
> changing into prefix using startprefix which gave me this path:
>
> PATH="/usr/local/gentoo/usr/sbin:/usr/local/gentoo/usr/bin:/usr/local/gentoo/sbin:/usr/local/gentoo/bin:/usr/local/gentoo/opt/bin:/usr/local/gentoo/usr/i686-apple-darwin9/binutils-bin/20080215:/usr/local/gentoo/usr/i686-apple-darwin9/gcc-bin/4.0.1:/usr/sbin:/usr/bin:/sbin:/bin"
>
> and those binaries:
>
> root@esgaroth:/usr/local/gentoo/usr/bin $ which gcc
> /usr/local/gentoo/usr/bin/gcc
> root@esgaroth:/usr/local/gentoo/usr/bin $ which i686-apple-darwin9-gcc
> /usr/local/gentoo/usr/bin/i686-apple-darwin9-gcc
> root@esgaroth:/usr/local/gentoo/usr/bin $ which ld
> /usr/local/gentoo/usr/bin/ld

Those all are the wrappers

> and I still get:
>
> michael@esgaroth:~ # otool -L /usr/local/gentoo/usr/lib/libglib-2.0.dylib
> /usr/local/gentoo/usr/lib/libglib-2.0.dylib:
> /usr/local/gentoo/usr/lib/libglib-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0)
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

This one is obviously wrong, the rest is correct. Question is, do you
have /usr/local/gentoo/lib/libiconv.2.dylib, and if so, what does
otool -L /usr/local/gentoo/lib/libiconv.2.dylib report?

> /usr/local/gentoo/usr/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.1.0)
> /usr/local/gentoo/usr/lib/gcc/i686-apple-darwin9/4.0.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> --
> bye,
> Micha
> --
> gentoo-alt@lists.gentoo.org mailing list
>

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

On Thu, Mar 27, 2008 at 07:52:16PM +0100, Fabian Groffen wrote:

> > > This is exactly the reason we are using wrappers that inject those
> > > flags. If gcc and ld aren't first in your default search-path,
> > > things
> > > will get difficult.
> > /usr/local/gentoo/usr/bin/gcc
> > /usr/local/gentoo/usr/bin/i686-apple-darwin9-gcc
> > /usr/local/gentoo/usr/bin/ld

> Those all are the wrappers

Ah. Shouldn't it contain some tweaking of CFLAGS then?

# strings /usr/local/gentoo/usr/bin/gcc | grep CFLAGS
CFLAGS_%s

> > michael@esgaroth:~ # otool -L /usr/local/gentoo/usr/lib/libglib-2.0.dylib
> > /usr/local/gentoo/usr/lib/libglib-2.0.dylib:
> > /usr/local/gentoo/usr/lib/libglib-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0)
> > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

> This one is obviously wrong, the rest is correct. Question is, do you
> have /usr/local/gentoo/lib/libiconv.2.dylib, and if so, what does
> otool -L /usr/local/gentoo/lib/libiconv.2.dylib report?

# otool -L /usr/local/gentoo/lib/libiconv.2.dylib
/usr/local/gentoo/lib/libiconv.2.dylib:
/usr/local/gentoo/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/gentoo/usr/lib/gcc/i686-apple-darwin9/4.0.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
--
bye, Micha
--
gentoo-alt@lists.gentoo.org mailing list

On Thu, Mar 27, 2008 at 08:11:13PM +0100, Michael Weiser wrote:

> > Those all are the wrappers
> Ah. Shouldn't it contain some tweaking of CFLAGS then?

They seem to be working anyway. I'll just emerge -ate world my prefix a
couple of times and see if libiconv cleans itself out.
--
Thanks,
Micha
--
gentoo-alt@lists.gentoo.org mailing list

On 27-03-2008 20:11:13 +0100, Michael Weiser wrote:
> On Thu, Mar 27, 2008 at 07:52:16PM +0100, Fabian Groffen wrote:
>
> > > > This is exactly the reason we are using wrappers that inject those
> > > > flags. If gcc and ld aren't first in your default search-path,
> > > > things
> > > > will get difficult.
> > > /usr/local/gentoo/usr/bin/gcc
> > > /usr/local/gentoo/usr/bin/i686-apple-darwin9-gcc
> > > /usr/local/gentoo/usr/bin/ld
>
> > Those all are the wrappers
>
> Ah. Shouldn't it contain some tweaking of CFLAGS then?
>
> # strings /usr/local/gentoo/usr/bin/gcc | grep CFLAGS
> CFLAGS_%s

No, GCC is compiled in such a way that the prefix include path belongs
to its default search path.

> > > michael@esgaroth:~ # otool -L /usr/local/gentoo/usr/lib/libglib-2.0.dylib
> > > /usr/local/gentoo/usr/lib/libglib-2.0.dylib:
> > > /usr/local/gentoo/usr/lib/libglib-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0)
> > > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
>
> > This one is obviously wrong, the rest is correct. Question is, do you
> > have /usr/local/gentoo/lib/libiconv.2.dylib, and if so, what does
> > otool -L /usr/local/gentoo/lib/libiconv.2.dylib report?
>
> # otool -L /usr/local/gentoo/lib/libiconv.2.dylib
> /usr/local/gentoo/lib/libiconv.2.dylib:
> /usr/local/gentoo/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> /usr/local/gentoo/usr/lib/gcc/i686-apple-darwin9/4.0.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

Then your libiconv is compiled correctly, it is just not clear to me how
glib can miss it. Actually, that's not your bug, but mine, as my system
has the same problem.


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

On 27-03-2008 21:25:39 +0100, Fabian Groffen wrote:
> On 27-03-2008 20:11:13 +0100, Michael Weiser wrote:
> > On Thu, Mar 27, 2008 at 07:52:16PM +0100, Fabian Groffen wrote:
[snip]
> Then your libiconv is compiled correctly, it is just not clear to me how
> glib can miss it. Actually, that's not your bug, but mine, as my system
> has the same problem.

I fixed this, it is due to libtool not knowing about prefix lib dirs.
This is a problem that I don't have a good solution for (yet). It is
basically asking for riddance of the wrappers...


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