F18 buildroot broken (libtool / gcc upgrade problem)?

[Richard W.M. Jones]

This doesn't look right ...

DEBUG util.py:257:  Error: Package: libtool-2.4.2-6.fc18.x86_64 (build)
DEBUG util.py:257:             Requires: gcc = 4.7.1
DEBUG util.py:257:             Installed: gcc-4.7.2-2.fc18.x86_64 (@build/$releasever)
DEBUG util.py:257:                 gcc = 4.7.2-2.fc18
DEBUG util.py:257:   You could try using --skip-broken to work around the problem
DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Richard W.M. Jones]

On Sun, Sep 23, 2012 at 10:12:51AM +0100, Richard W.M. Jones wrote:
>  This doesn't look right ...
>  
>  DEBUG util.py:257:  Error: Package: libtool-2.4.2-6.fc18.x86_64 (build)
>  DEBUG util.py:257:             Requires: gcc = 4.7.1
>  DEBUG util.py:257:             Installed: gcc-4.7.2-2.fc18.x86_64 (@build/$releasever)
>  DEBUG util.py:257:                 gcc = 4.7.2-2.fc18
>  DEBUG util.py:257:   You could try using --skip-broken to work around the problem
>  DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest 
Actually the same thing happened last time.  I even posted
about it:

https://lists.fedoraproject.org/pipermail/devel/2012-June/169489.html

So I'll go ahead and rebuild libtool.  There must surely be a better
way to deal with this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Richard W.M. Jones]

On Sun, Sep 23, 2012 at 10:17:10AM +0100, Richard W.M. Jones wrote:
>  On Sun, Sep 23, 2012 at 10:12:51AM +0100, Richard W.M. Jones wrote:
>  > This doesn't look right ...
>  > 
>  > DEBUG util.py:257:  Error: Package: libtool-2.4.2-6.fc18.x86_64 (build)
>  > DEBUG util.py:257:             Requires: gcc = 4.7.1
>  > DEBUG util.py:257:             Installed: gcc-4.7.2-2.fc18.x86_64
> (@build/$releasever)
>  > DEBUG util.py:257:                 gcc = 4.7.2-2.fc18
>  > DEBUG util.py:257:   You could try using --skip-broken to work around the problem
>  > DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest
>  
>  Actually the same thing happened last time.  I even posted
>  about it:
>  
>  https://lists.fedoraproject.org/pipermail/devel/2012-June/169489.html
>  
>  So I'll go ahead and rebuild libtool. 
... which has been done already.

>  There must surely be a better
>  way to deal with this? 
There are a few of these ...

$ grep /usr/lib/gcc /usr/bin/libtool
sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.1 /usr/lib64 /lib64
"
compiler_lib_search_dirs="/usr/lib/gcc/x86_64-redhat-linux/4.7.1
/usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64 /lib/../lib64 /usr/lib/../lib64
/usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../.."
predep_objects="/usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.1/crtbeginS.o"
[etc]

But it looks like it'd be possible to replace 4.7.1 with the partial
output of `gcc --version`.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Tom Hughes]

On 23/09/12 10:20, Richard W.M. Jones wrote:

>  $ grep /usr/lib/gcc /usr/bin/libtool
>  sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.1 /usr/lib64 /lib64
> "
>  compiler_lib_search_dirs="/usr/lib/gcc/x86_64-redhat-linux/4.7.1
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64 /lib/../lib64 /usr/lib/../lib64
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../.."
>  predep_objects="/usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/crtbeginS.o"
>  [etc]
>
>  But it looks like it'd be possible to replace 4.7.1 with the partial
>  output of `gcc --version`. 
Using "gcc -dumpversion" will make it even easier ;-)

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Richard W.M. Jones]

On Sun, Sep 23, 2012 at 10:25:25AM +0100, Tom Hughes wrote:
>  On 23/09/12 10:20, Richard W.M. Jones wrote:
>  
>  >$ grep /usr/lib/gcc /usr/bin/libtool
>  >sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.1 /usr/lib64
> /lib64 "
>  >compiler_lib_search_dirs="/usr/lib/gcc/x86_64-redhat-linux/4.7.1
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64 /lib/../lib64 /usr/lib/../lib64
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../.."
>  >predep_objects="/usr/lib/gcc/x86_64-redhat-linux/4.7.1/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/4.7.1/crtbeginS.o"
>  >[etc]
>  >
>  >But it looks like it'd be possible to replace 4.7.1 with the partial
>  >output of `gcc --version`.
>  
>  Using "gcc -dumpversion" will make it even easier ;-) 
Yup!

No surprises that the build system of libtool is as crazy as the
program itself.  I can't even find how the 'libtool' script
is created ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Kevin Kofler]

Richard W.M. Jones wrote:
>  No surprises that the build system of libtool is as crazy as the
>  program itself.  I can't even find how the 'libtool' script
>  is created ... 
Sigh, libtool is probably the most braindead of the autocrap. Good luck with 
it, you'll need it! ;-)

        Kevin Kofler