# [gelöst] Warum werden Anwendungen gegen Bibliotheken

## Klaus Meier

Also jetzt noch mal der ganze Satz: Warum werden Anwendungen gegen Bibliotheken gelinkt, die sie nicht brauchen?

Heute morgen, das Flag opencore-amr wurde entfernt. mplayer wurde ohne dieses Flag übersetzt. Ein emerge --depclean hat daraufhin ja auch was gelöscht. Und ein revdep-rebuild brachte, dass ich mplayer noch mal übersetzen soll, weil eine Bibliothek fehlt. Und das ist eigentlich jedes Mal der Fall.

Also, alles zwei mal. Nur warum wird mplayer beim ersten Mal gegen eine Bibliothek gelinkt, die es gemäß der Flags gar nicht nutzen soll?Last edited by Klaus Meier on Mon Apr 26, 2010 7:38 am; edited 1 time in total

----------

## mv

Zunächst mal wurde USE=opencore-amr nicht entfernt, sondern nur umbenannt in USE=amr. Es geht aus Deinem Posting nicht hervor, ob amr jetzt bei Dir gesetzt ist.

Da Du anscheinend die opencore-amr-Abhängigkeit "verloren" hast, nehme ich an, dass Du amr nicht in Deinen USE-Flag hast, aber opencore-amr darin hattest.

Zu Deiner Frage: Im mplayer-1.0_rc4_p20091026-r1.ebuild werden ./configure ausdrücklich bei Nichtbenutzung von amr die Flags --disable-libopencore_amrnb und --disable-libopencore_amrwb übergeben. Im mplayer-1.0_rc4_p20100213-r1.ebuild hängen die Parameter gar nicht von USE=amr ab, so dass sich ./configure also auf die Auto-Detection verlässt. Genau aus dem Grund, dass das Ergebnis dann implizit von den installierten Paketen statt von den USE-Flags abhängt, will man das bei Gentoo eigentlich nicht haben. Du solltest also einen Bugreport absetzen...

----------

## Klaus Meier

Das ist aber ein Verhalten, was ich eigentlich immer habe, wenn ich ein Flag entferne. Ok, leuchte mir jetzt ein, configure schaut nach, was da ist und nicht, was man in den Flags gesetzt hat. Aber das ist kein Bug im mplayer-ebuild, das ist allgemein so.

----------

## musv

Ich hatte das Problem auch mal. Das AMR-Zeug ist schon seit sehr langer Zeit mit diesem Verhalten drin. Ich wurde damals hier im Forum (welches weiß ich nicht mehr) "korrigiert", dass der mplayer ja das Ziel haben sollte, erstmal alles abspielen zu können. Was man nicht will, muss mach explizit rausschmeißen. Bei mir funktioniert das so:

```
# mplayer hat 'ne Meise und will alles installieren

media-video/mplayer -amrnb -amrwb -cdio -dirac -dvdnav -enca -nemesi -pnm -schroedinger -speex
```

Ob sich die USE-Flags inzwischen geändert haben, kann ich nicht sagen. Hab seit Monaten kein Update mehr gemacht.

----------

## mv

 *Klaus Meier wrote:*   

> configure schaut nach, was da ist und nicht, was man in den Flags gesetzt hat. Aber das ist kein Bug im mplayer-ebuild, das ist allgemein so.

 

Es ist ein Bug: Ein korrektes Gentoo-Ebuild sollte entweder --enable-foo oder --disable-foo übergeben, damit genau der von Dir beschriebene Effekt nicht auftritt; falls das ./configure-Skript nur automatisch erkennen kann, müsste es sogar gepatcht werden.

Du hast natürlich recht, dass dies einer der Bugs ist, die am leichtesten übersehen (und oft nicht gemeldet) werden, weshalb man das fehlerhafte Verhalten leider immer wieder beobachten kann.

Solange man nur ein System hat, ist es auch nicht so schlimm: Richtig Probleme bekommt man erst, wenn man von solchen fehlerhaften Ebuilds Binärpakete baut, die dann auf dem Zielsystem trotz korrekter USE- und CFLAGS nicht laufen...

----------

## mv

 *musv wrote:*   

> Ich hatte das Problem auch mal. Das AMR-Zeug ist schon seit sehr langer Zeit mit diesem Verhalten drin.

 

Du sprichst von etwas anderem, nämlich vom Default-Setting der USE-flags. Egal, wie sich da die Developer entscheiden, wird es immer Benutzer geben, die mit dieser Entscheidung nicht einverstanden sind. Was aber nicht schlimm ist, weil man das ja leicht in /etc/portage/package.use ändern kann, was Du ja auch getan hast.

Das Problem, um das es hier geht, ist aber, dass das amr USE-Flag zwar in den Abhängigkeiten berücksichtigt, zum Bauen des Paketes aber ignoriert wird (zumindest in der Testing-Version von mplayer) - egal ob es an oder aus ist. Wenn es an ist, tritt das Problem "zufälligerweise" nicht auf, weil ja die Abhängigkeit vorher installiert sein muss, und die Auto-Detection daher Support für amr einkompiliert. Dummerweise passiert das aber eben auch, wenn das USE-Flag aus ist und opencore-amr installiert ist.

Und hier geht es eben nicht um eine Geschmacksache oder politische Entscheidung: Das Verhalten ist schlicht fehlerhaft.

----------

## Klaus Meier

Danke für die Erklärung. Ist mir jetzt klar, was da passiert und warum. Werde das mal weiter beobachten, denn da verhalten sich einige Pakete so.

Edit: Noch mal nachgedacht. In diesem Fall ist es nicht mal ein Bug. Denn ich habe das Flag opencore-amr ja nicht deaktiviert, es wurde ja komplett entfernt. D.h., beim Lauf von ./configure wurde das natürlich weder als enable noch als disable übergeben sondern gar nicht. Wie denn auch, wenn es das gar nicht mehr gibt.

Also wenn man weiß, um was es geht, am Besten schon vorher löschen, dann spart man sich einen Durchlauf.Last edited by Klaus Meier on Mon Apr 26, 2010 7:24 am; edited 1 time in total

----------

## astaecker

Dieses Verhalten des Buildsystemes nennt sich "automagic" und im GDP gibt sogar einen Artikel darüber: Automagic dependencies, what they are and how to fix them.

----------

## Klaus Meier

 *arlsair wrote:*   

> Dieses Verhalten des Buildsystemes nennt sich "automagic" und im GDP gibt sogar einen Artikel darüber: Automagic dependencies, what they are and how to fix them.

 

Ok, danke, damit ist das "Problem" ausführlich erörtert. Es kann also sein, dass Anwendungen über eine Funktionalität verfügen, die ich dür diese Anwendung gar nicht möchte, nur weil die entsprechende Funktionalität vorhanden ist. Irgendwie nicht optimal.

----------

