Re: [gentoo-user] Re: dev-libs/libgamin-0.1.10-r2 fails to emerge on a multilib profile
On Saturday 27 February 2010 21:45:13 Arttu V. wrote: On 2/27/10, Mick michaelkintz...@gmail.com wrote: On Saturday 27 February 2010 19:04:09 walt wrote: On 02/27/2010 10:04 AM, Mick wrote: Hi All, I am trying to install Gentoo on a i7 x86_64 arch machine and libgamin fails when I try to emerge syslog-ng (it's a dependency of it). This is my first 64bit machine, so I am not sure if I have made more mistakes than usual (LOL). This is the error: libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/gamin.o -Wl,-rpath -Wl,/var/tmp/portage/dev-libs/libgamin-0.1.10-r2/work/gamin-0.1.10/lib gam in/.libs ../libgamin/.libs/libgamin-1.so /usr/bin /usr/sbin /bin /sbin ^ -lpthread -march=core2 -msse4 -mcx16 -msahf -Wl,-O1 -Wl,-soname -Wl,_gamin.so -o .libs/_gamin.so /usr/bin: file not recognized: Is a directory Cool, a new libtool trick. It's trying to link an object file with a directory? Dunno where the real error is, but I'd start with the old shotgun approach by running lafilefixer --justfixit and see if it helps. That was my first thought too. I ran lafixer and revdep-rebuild after emerging these and the error shown above came up. grep for pkg-config inside the config.log (and maybe build.log as well). I'm betting on pkg-config not being found, although the ebuild seems to list it as a dependency. (Maybe your chroot settings affect the path?) IIRC another package did the same for me some months ago (sorry, can't remember which). If it couldn't find pkg-config it would still complete configure phase without errors -- but cflags and libs variables that were supposed to be filled with various `pkg-config --libs foo` outputs were in fact filled with the paths from which pkg-config was searched for (in vain) during configuration. And IIRC the result looked nearly identical to the situation here. Thanks Arttu V. I will look at this when I boot next - I am trying to chainload the new install from Windows 7 to see if the error repeats outside the chroot and it is a struggle so far. Do you recall what your fix was? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: dev-libs/libgamin-0.1.10-r2 fails to emerge on a multilib profile
On 02/27/2010 10:04 AM, Mick wrote: Hi All, I am trying to install Gentoo on a i7 x86_64 arch machine and libgamin fails when I try to emerge syslog-ng (it's a dependency of it). This is my first 64bit machine, so I am not sure if I have made more mistakes than usual (LOL). This is the error: libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/gamin.o -Wl,-rpath -Wl,/var/tmp/portage/dev-libs/libgamin-0.1.10-r2/work/gamin-0.1.10/libgamin/.libs ../libgamin/.libs/libgamin-1.so /usr/bin /usr/sbin /bin /sbin ^ -lpthread -march=core2 -msse4 -mcx16 -msahf -Wl,-O1 -Wl,-soname -Wl,_gamin.so -o .libs/_gamin.so /usr/bin: file not recognized: Is a directory Cool, a new libtool trick. It's trying to link an object file with a directory? Dunno where the real error is, but I'd start with the old shotgun approach by running lafilefixer --justfixit and see if it helps.
Re: [gentoo-user] Re: dev-libs/libgamin-0.1.10-r2 fails to emerge on a multilib profile
On Saturday 27 February 2010 19:04:09 walt wrote: On 02/27/2010 10:04 AM, Mick wrote: Hi All, I am trying to install Gentoo on a i7 x86_64 arch machine and libgamin fails when I try to emerge syslog-ng (it's a dependency of it). This is my first 64bit machine, so I am not sure if I have made more mistakes than usual (LOL). This is the error: libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/gamin.o -Wl,-rpath -Wl,/var/tmp/portage/dev-libs/libgamin-0.1.10-r2/work/gamin-0.1.10/libgam in/.libs ../libgamin/.libs/libgamin-1.so /usr/bin /usr/sbin /bin /sbin ^ -lpthread -march=core2 -msse4 -mcx16 -msahf -Wl,-O1 -Wl,-soname -Wl,_gamin.so -o .libs/_gamin.so /usr/bin: file not recognized: Is a directory Cool, a new libtool trick. It's trying to link an object file with a directory? Dunno where the real error is, but I'd start with the old shotgun approach by running lafilefixer --justfixit and see if it helps. That was my first thought too. I ran lafixer and revdep-rebuild after emerging these and the error shown above came up. Does it matter that I am in a chroot (I'm sure I ran all the correct incantations to get there). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: dev-libs/libgamin-0.1.10-r2 fails to emerge on a multilib profile
On 2/27/10, Mick michaelkintz...@gmail.com wrote: On Saturday 27 February 2010 19:04:09 walt wrote: On 02/27/2010 10:04 AM, Mick wrote: Hi All, I am trying to install Gentoo on a i7 x86_64 arch machine and libgamin fails when I try to emerge syslog-ng (it's a dependency of it). This is my first 64bit machine, so I am not sure if I have made more mistakes than usual (LOL). This is the error: libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/gamin.o -Wl,-rpath -Wl,/var/tmp/portage/dev-libs/libgamin-0.1.10-r2/work/gamin-0.1.10/libgam in/.libs ../libgamin/.libs/libgamin-1.so /usr/bin /usr/sbin /bin /sbin ^ -lpthread -march=core2 -msse4 -mcx16 -msahf -Wl,-O1 -Wl,-soname -Wl,_gamin.so -o .libs/_gamin.so /usr/bin: file not recognized: Is a directory Cool, a new libtool trick. It's trying to link an object file with a directory? Dunno where the real error is, but I'd start with the old shotgun approach by running lafilefixer --justfixit and see if it helps. That was my first thought too. I ran lafixer and revdep-rebuild after emerging these and the error shown above came up. grep for pkg-config inside the config.log (and maybe build.log as well). I'm betting on pkg-config not being found, although the ebuild seems to list it as a dependency. (Maybe your chroot settings affect the path?) IIRC another package did the same for me some months ago (sorry, can't remember which). If it couldn't find pkg-config it would still complete configure phase without errors -- but cflags and libs variables that were supposed to be filled with various `pkg-config --libs foo` outputs were in fact filled with the paths from which pkg-config was searched for (in vain) during configuration. And IIRC the result looked nearly identical to the situation here. -- Arttu V.
