# gcc-4.4.5 wurde Heute installiert, obwohl neuer vorhanden?

## Randy Andy

Hallo Leute,

hab mich Heute bei meinem obligatorischen system/world Update ein wenig über die installation von sys-devel/gcc-4.4.5 gewundert weil:

Ich bin ich auf ~amd64 arch und habe seit dem 18.12.10 gcc-4.5.2 installiert, guckt ihr hier:

```

eix -I gcc

[I] sys-devel/gcc

     Available versions:  

        (2.95)  *2.95.3-r9 ~*2.95.3-r10!s

        (3.1)   *3.1.1-r2

        (3.2)   **3.2.2!s *3.2.3-r4

        (3.3)   (~)3.3.6-r1!s

        (3.4)   3.4.6-r2!s

        (4.0)   ~*4.0.4!s

        (4.1)   4.1.2!s

        (4.2)   (~)4.2.4-r1!s

        (4.3)   (~)4.3.3-r2!s 4.3.4!s (~)4.3.5!s (~)4.3.6!s

        (4.4)   (~)4.4.2!s (~)4.4.3-r3!s 4.4.4-r2!s 4.4.5!s

        (4.5)   (~)4.5.1-r1!s (~)4.5.2!s

        (4.6)   [M]**4.6.0!s [M]**4.6.1!s

        {altivec bootstrap boundschecking build d doc fixed-point fortran gcj go graphite gtk hardened ip28 ip32r10k java libffi lto mudflap multilib multislot nls nocxx nopie nossp nptl objc objc++ objc-gc openmp static test vanilla}

     Installed versions:  4.5.2(4.5)!s(14:08:10 28.12.2010)(fortran gcj gtk mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -graphite -hardened -libffi -lto -multislot -n32 -n64 -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla)

     Homepage:            http://gcc.gnu.org/

     Description:         The GNU Compiler Collection
```

Ausserdem update ich fast auf täglicher Basis, und bisher wollte er mir das nie nachinstallieren, da ich ja schon erfolgreich auf die neuere Version umgestellt hatte.

Also was soll das jetzt? 

Klar installiert er das in 'nem Slot, soweit nicht so schlimm, trotzdem wundere ich mir über das Verhalten, und kann es mir nicht ganz erklären.

Das Changelog von GCC sagt mir auch nichts hilfreiches dazu.

Infos:

Vor der installation:

```
ocalhost andy # gcc-config -l

 [1] i686-pc-linux-gnu-4.5.2 *

 [2] x86_64-pc-linux-gnu-4.5.2 *

```

Nach der installattion Heute:

```

localhost andy # gcc-config -l

 [1] i686-pc-linux-gnu-4.5.2 *

 [2] x86_64-pc-linux-gnu-4.4.5

 [3] x86_64-pc-linux-gnu-4.5.2 *

```

Kann mir das Jemand erklären woran das liegt?

----------

## Christian99

```
equery d gcc
```

 kann dir das sagen. bei mir ist es das nvidia-cuda-toolkit, welches explizit den slot gcc:4.4 verlangt.

aber das ist schon seit ein paar wochen. bei dir ist es dann vermutlich was anderes.

----------

## Randy Andy

Danke Christian,

damit scheinst du auch in meinem Fall recht zu haben:

```

equery d gcc

 * These packages depend on gcc:

app-admin/eselect-python-20100321 (>=sys-devel/gcc-3.4)

app-text/pdftk-1.44 (>=sys-devel/gcc-4.3.1[gcj])

cross-i686-pc-linux-gnu/glibc-2.13-r2 (>=sys-devel/gcc-3.4.4)

                                      (>=sys-devel/gcc-4.3)

                                      (cross-i686-pc-linux-gnu/gcc)

dev-db/mysql-5.1.56 (>=sys-devel/gcc-3.4.6)

dev-java/icedtea6-bin-1.10.2 (>=sys-devel/gcc-4.3)

dev-libs/mpc-0.9 (elibc_SunOS ? >=sys-devel/gcc-4.5)

dev-util/nvidia-cuda-toolkit-4.0 (sys-devel/gcc:4.4)

media-gfx/blender-2.49b-r2 (sys-devel/gcc[openmp?])

sci-geosciences/googleearth-6.0.3.2197 (>=sys-devel/gcc-4.2[-nocxx])

sys-devel/llvm-2.9-r2 (>=sys-devel/gcc-3.0)

sys-libs/glibc-2.13-r3 (>=sys-devel/gcc-3.4.4)

                       (arm ? >=sys-devel/gcc-4.1.0)

                       (x86 ? >=sys-devel/gcc-4.3)

                       (amd64 ? >=sys-devel/gcc-4.3)

                       (ppc ? >=sys-devel/gcc-4.1.0)

                       (ppc64 ? >=sys-devel/gcc-4.1.0)

virtual/fortran-0 (sys-devel/gcc[fortran])

                  (openmp ? sys-devel/gcc[fortran,openmp?])

www-client/firefox-5.0-r2 (pgo ? >=sys-devel/gcc-4.5)

```

Aber warum beharrt nvidia-cuda-toolkit-4.0 auf der gcc-4.4er Version, denn bei mir ließ es sich auch mit aktiviertem gcc-4.5.2 installieren, oder bewirkt schon das alleinige Vorhandensein von gcc-4.4 etwas, auch wenn dessen Profil garnicht aktiviert ist - ich denke nicht.

```
gcc-config -l

 [1] i686-pc-linux-gnu-4.5.2 *

 [2] x86_64-pc-linux-gnu-4.4.5

 [3] x86_64-pc-linux-gnu-4.5.2 *

```

Ist die Abhängigkeit also für nvidia-cuda-toolkit-4.0 nur falsch definiert, sprich müsste es auch hier eigentlich (>=sys-devel/gcc-4.4) heissen?

Andy.

----------

## Christian99

ich vermute mal, dass die vorgabe von nvidia kommt und übernommen wurde. was soll man bei binary-paketen auch machen. deswegen lässt sich es ja auch installieren. die dateien werden nur kopiert und nix kompiliert. möglicherweise gibts bei der ausführung probleme.

----------

## Randy Andy

Hast ja recht,  was die binären Pakete angeht.

Hab aus Spaß mal Gestern das nvidia-cuda-toolkit-4.0 remerged um zu sehen ob es danach vielleicht gegen die aktive Version 4.5.2 des gcc gelinkt ist, dem ist aber nicht so. Dafür hab ich nun das Problem, dass revdep-rebuild ständig meckert wie folgt:

```
[ 1% ]  *   broken /opt/cuda/computeprof/bin/cudaapitrace32.so (requires libcudart.so.4)
```

und mir danach wieder dev-util/nvidia-cuda-toolkit-4.0 installiert, das Problem bleibt aber gleich.

ein ldd /opt/cuda/computeprof/bin/cudaapitrace32.so sagt mir:

```

ldd /opt/cuda/computeprof/bin/cudaapitrace32.so

ldd: warning: you do not have execution permission for `/opt/cuda/computeprof/bin/cudaapitrace32.so'

        linux-gate.so.1 =>  (0xffffe000)

        libcuda.so.1 => /usr/lib32/libcuda.so.1 (0xf6d0f000)

        libcudart.so.4 => not found

        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libstdc++.so.6 (0xf6c21000)

        libm.so.6 => /lib32/libm.so.6 (0xf6bfa000)

        libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf6bdf000)

        libc.so.6 => /lib32/libc.so.6 (0xf6a7f000)

        libpthread.so.0 => /lib32/libpthread.so.0 (0xf6a65000)

        libz.so.1 => /lib32/libz.so.1 (0xf6a52000)

        libdl.so.2 => /lib32/libdl.so.2 (0xf6a4e000)

        /lib/ld-linux.so.2 (0xf77b5000)

```

ein locate libcudart.so.4 liefert:

```

/opt/cuda/lib64/libcudart.so.4

/opt/cuda/lib64/libcudart.so.4.0.17

```

und ein 

```

ldd /opt/cuda/lib64/libcudart.so.4.0.17

        linux-vdso.so.1 =>  (0x00007fff5b1fa000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc4e9339000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc4e911c000)

        librt.so.1 => /lib64/librt.so.1 (0x00007fc4e8f12000)

        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6 (0x00007fc4e8c09000)

        libm.so.6 => /lib64/libm.so.6 (0x00007fc4e8987000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc4e8770000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fc4e83e5000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fc4e97d5000)

```

und noch:

```

 ldd /opt/cuda/lib64/libcudart.so.4

        linux-vdso.so.1 =>  (0x00007fff21dff000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007f459b349000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f459b12c000)

        librt.so.1 => /lib64/librt.so.1 (0x00007f459af22000)

        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6 (0x00007f459ac19000)

        libm.so.6 => /lib64/libm.so.6 (0x00007f459a997000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f459a780000)

        libc.so.6 => /lib64/libc.so.6 (0x00007f459a3f5000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f459b7e5000)

```

Hm, ob ich wohl 

/opt/cuda/lib64/libcudart.so.4

mal löschen soll, um das revdep-rebuild Problem quitt zu werden...

Was denkt ihr?

Andy.

----------

## Christian99

ja, das problem kenn ich, obwohl ich es nicht ganz verstehe. einmal hab ichs weggekriegt, weiß aber nicht mehr wie. proobier einfach mal zu löschen und schau was passiert.

----------

## Randy Andy

Ah,

vermutlich meinst du diese Posting https://forums.gentoo.org/viewtopic-t-859591-start-0.html  :Wink: 

Schade das du nicht mehr weisst wie du's gelöst hast, so muss ich halt noch ein wenig experimentieren, denn das Lösschen hat nix gebracht.

Bis später mal.

Andy

----------

## Dorsai!

Ich konnte das abstellen indem ich global den opencl useflag entfernt habe. War eh nur bei wine und imagemagick in verwendung. Dieser benötigt ein altes nvidia sdk und dieses braucht offensichtlich den alten gcc.

Ist halt nur eine notlösung, aber für momentan genug, da ich opencl eh nicht brauch.

----------

## Randy Andy

Dorsai,

das ist auch 'ne Idee. Hab also mal nachgeschaut mit 'nem equery h opencl.

Ist bei mir das gleiche, lediglich wine und imagemagick machen davon gebrauch - also fott damit   :Wink: 

Danke für den Hinweis auf diesen Workaround. Wieso ich da nicht selber drauf gekommen bin...

Servus, Andy.

----------

