On 14.02.2017 03:12, meino.cra...@gmx.de wrote:
> Johannes Rosenberger <gen...@jorsn.eu> [17-02-14 02:43]:
>> On 13.02.2017 19:20, meino.cra...@gmx.de wrote:
>>> Johannes Rosenberger <gen...@jorsn.eu> [17-02-13 19:04]:
>>>> On 13.02.2017 17:57, meino.cra...@gmx.de wrote:
>>>>
>>>>> Hogren <hog...@iiiha.com> [17-02-13 17:06]:
>>>>>> On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> got a mysterious error message this morning (still building a new
>>>>>>> root...)
>>>>>>>
>>>>>>> One of the updates was gnutls:
>>>>>>> It ends with:
>>>>>>> ...
>>>>>>> checking for i686-pc-linux-gnu-pkg-config...
>>>>>>> /usr/bin/i686-pc-linux-gnu-pkg-config
>>>>>>> checking pkg-config is at least version 0.9.0...
>>>>>>> /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure:
>>>>>>> line 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
>>>>>>> no
>>>>>>> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
>>>>>>> checking whether the C compiler works... yes
>>>>>>> checking for C compiler default output file name... a.out
>>>>>>> checking for suffix of executables...
>>>>>>> checking whether we are cross compiling... configure: error: in
>>>>>>> `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
>>>>>>> configure: error: cannot run C compiled programs.
>>>>>>> If you meant to cross compile, use `--host'.
>>>>>>> See `config.log' for more details
>>>>>>> ...
>>>>>>>
>>>>>>> I tried:
>>>>>>> computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
>>>>>>> not a dynamic executable
>>>>>>> computer# /usr/bin/i686-pc-linux-gnu-pkg-config
>>>>>>> zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
>>>>>>>
>>>>>>> computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
>>>>>>> /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel
>>>>>>> 80386, version 1 (SYSV), dynamically linked, interpreter
>>>>>>> /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
>>>>>>>
>>>>>>> I choosed multilib right from the beginning of this adventure ...
>>>>>>>
>>>>>>> How can I check, whether the problem is caysed by gnutls or by the
>>>>>>> system setup (regarding 32bit)?
>>>>>>>
>>>>>>> Cheers
>>>>>>> Meino
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Can you give us more details of what do you want to do, what do you
>>>>>> already do, etc.
>>>>>>
>>>>>> Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable)
>>>>>> permission ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hogren
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> More mysterious hickups:
>>>>>
>>>>>>>> Regenerating /etc/ld.so.cache...
>>>>> /sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.
>>>>>
>>>>> Did it screwed up my new root?
>>>>>
>>>>> Cheers
>>>>> Meino
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Maybe. But maybe it is fixable. /lib64/ld-linux.so.2 is a symlink to
>>>> glibc. But glibc cannot be wholly broken because if it were, then
>>>> nothing would work at all.
>>>>
>>>> I'd first investigate if only the symlink needs to be fixed (should
>>>> point to /lib/ld-<version>.so).
>>>>
>>>> Have you updated glibc recently?Or any other important package/package
>>>> from @system?
>>>> Have you tried if 'revdep-rebuild' finds any broken libraries?
>>>>
>>>> If glibc is really broken you can
>>>>
>>>> 1. chroot into a stage3
>>>> 2. build a binpkg (type 'quickpkg glibc')
>>>> 3. copy the binpkg from
>>>> '/usr/portage/packages/sys-libs/glibc-*.tbz2' in the stage3 to
>>>> the same directory in your new root
>>>> 4. install the binary glibc ('emerge <full path to glibc binpkg>')
>>>>
>>>> Then you should have a clean glibc install.
>>>>
>>>> If you suspect an update of breaking anything you can always build
>>>> binary packages ahead. They are built from the installed package, so you
>>>> don't have any additional compiling. Then you can roll back quickly if
>>>> anything is damaged.
>>>>
>>>> If you have a working glibc then you could also try re-emerging pkg-config.
>>>>
>>>> Regards
>>>> Johannes
>>>>
>>>>
>>> Hi Johannes,
>>>
>>> thanks for your offered help! :)
>>>
>>> I fixed that symlink but I ran into more weird problems... :(
>>> Normally I alway run a revdep-rebuild cycle after each
>>> update...
>>>
>>> How did you set ABI_X86 in make.conf?
>>> Do you use multilib or a pure 64bit setup?
>>>
>>> Cheers
>>> Meino
>>>
>> Hi Meino,
>>
>> you are welcome!
>>
>> With the portage FEATURE 'preserve-libs' (active by default) you don't
>> need to revep-rebuild, normally. Just emerge @preserved-rebuild after
>> every update.
>>
>> Does pkg-config work, now? Can you describe your "weird problems"? Have
>> you emerged any potentially broken and important (e.g. from @system)
>> packages recently?
>>
>> Since I use a pure 64bit setup with abi_x86_32 activated selectively for
>> 399 packages (mostly graphics related, because i still have flash
>> installed), i have no ABI_X86 var in my make.conf but use a pure amd64
>> profile (where this var is set).
>> What do you need 32bit for? 3rd-party binaries?
>>
>> Regards
>> Johannes
>>
>>
>
> Hi Johannes,
>
> :)
>
> this morning I did a eix-sync; emerge.... again to log, what happens.
> I compressed the logfile and the output of qlop -l as hard as I can
> with 7zip.
>
> I emerge pkg-config but I make not THAT a difference...
>
> Hope the log are talking to you... ;)
>
> Cheers
> Meino
>
>
Those logs are telling me that the failures are really logged in
/var/tmp/portage/net-dns/libidn2-0.16-r1/work/libidn2-0.16-abi_x86_32.x86/config.log
and
/var/tmp/portage/media-libs/mesa-17.0.0/work/mesa-17.0.0-abi_x86_32.x86/config.log
And I see that you updated gcc and glibc recently. I suspect the
problems of being gcc/libtool related. From which gcc version did you
upgrade?
You should re-emerge libtool after configuring the new gcc.
Have a look at https://wiki.gentoo.org/wiki/Upgrading_GCC and
https://wiki.gentoo.org/wiki/Upgrading_from_gcc-4.x_to_gcc-5.x.
Regards
Johannes
