# [eseguibili fantasma] /bin/ar : chi è costui?

## cloc3

```

s939 ~ # emerge -1 dev-db/qdbm

...

cabin.c:3336: warning: ignoring return value of 'write', declared with attribute warn_unused_result

/bin/ar: invalid option -- 's'

BusyBox v1.15.3 (2010-04-02 08:17:53 CEST) multi-call binary

...

```

allora eseguo:

```

s939 ~ # qfile /bin/ar

s939 ~ #

```

risposta vuota.

sposto il file in /root, rilancio la compilazione di qdbm e la concludo felicemente.

controprova: rimetto ar al suo posto e la compilazione fallisce.

/bin/ar, tuttavia, non è un eseguibile fantasma, perché ne ho trovato traccia in man ar, e ho scoperto che si tratta di un programma per il trattamento di archivi.

qualcuno saprebbe darmi informazioni più precise, riguardo al pacchetto di provenienza?

----------

## Apetrini

Non è la prima volta che episodi di questo tipo vengono segnalati.

Sarebbe bene, una volta per tutte, capire perché c'è roba in giro per il sistema; e se si tratta di roba alla base dello stage3, perché non sono stati riempiti i VDB per riconoscere questi file.

Se qualcuno può spiegare bene la situazione, lo faccia....

P.s. Comunque dai un occhio qui http://www.gnu.org/software/binutils/

----------

## cloc3

 *Apetrini wrote:*   

> 
> 
> P.s. Comunque dai un occhio qui http://www.gnu.org/software/binutils/

 

```

cloc3@s939 ~ $ qlist binutils|grep /ar

/usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar

/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20.1/man/man1/ar.1.bz2

cloc3@s939 ~ $ genlop -l|head -n3

     Sun Jul 30 12:49:53 2006 >>> app-portage/gentoolkit-0.2.2

```

evidentemente il pacchetto è stato spostato fuori dai binari pubblici.

come puoi vedere, lavoro su un'installazione vecchissima (archeologica?).

evidentemente, il pacchetto si è perduto durante un upgrade che non è stato ripulito correttamente da emerge.

----------

## djinnZ

ar e ranlib li usavo ai tempi che furono per operare sulle librerie statiche .out . Non è che viene da una ricompilazione +/-multilib ?

Mi pare che sia stato rimosso dai sorgenti delle binutils e compilato solo con in casi particolari ma lo ho anche io e la mia installazione è decisamente più recente.

In ogni caso a suo tempo (quando c'erano i problemi di conversione dal 3.4. al 3.6 e la famigerata use ccc-compat con cui fare i conti) segnalai che nello stage3 erano mantenuti dei file del gcc 3.4 che incasinavano sistematicamente alcuni automake e revdep-rebuild e mi fu risposto che non era importante.

Ma è un bug.

----------

## Apetrini

Ho installazioni di ~1 anno fa sotto mano (roba server) e anche li c'è lo stesso problema. Rimango della teoria che siano file dello stage3 non "mappati" (e dovrebbero esserlo).

----------

## ago

@cloc3 nel mio sistema ho trovato queste info

```
devil ago # which -a ar

/usr/bin/ar
```

in più mi dice tranquillamente che fa parte di binutils (come anche a te del resto)

```
qfile ar | head -1

sys-devel/binutils (/usr/i686-pc-linux-gnu/binutils-bin/2.18/ar)
```

Forse l'unica diversità è che il tuo sta in /bin e non /usr/bin e che, fa fallire la compilazione

----------

## Apetrini

Ahh

Siamo stati di nuovo beffati dal triplo link innestato che viene creato dopo il merge...

Date on occhio a questo...

```

ariel ape # ls -al /usr/bin/ar

lrwxrwxrwx 1 root root 22 14 mag 17:40 /usr/bin/ar -> x86_64-pc-linux-gnu-ar

ariel ape # ls -al /usr/bin/x86_64-pc-linux-gnu-ar 

lrwxrwxrwx 1 root root 31 14 mag 17:40 /usr/bin/x86_64-pc-linux-gnu-ar -> /usr/x86_64-pc-linux-gnu/bin/ar

ariel ape # ls -al /usr/x86_64-pc-linux-gnu/bin/ar

lrwxrwxrwx 1 root root 47 14 mag 17:40 /usr/x86_64-pc-linux-gnu/bin/ar -> /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar

ariel ape # ls -al /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar 

-rwxr-xr-x 1 root root 56168 14 mag 17:40 /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar

ariel ape # paludis -o /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar 

* /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar

    sys-devel/binutils-2.20.1-r1:0::installed

        /usr/lib64/debug/usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar.debug

        /usr/x86_64-pc-linux-gnu/binutils-bin/2.20.1/ar

ariel ape # 

```

----------

## cloc3

 *Apetrini wrote:*   

> Ahh
> 
> Siamo stati di nuovo beffati
> 
> 

 

bravo.

ma non siamo stati beffati.

è solo colpa mia.

per fortuna, ho conservato nella root la copia originale del file incriminato, che la dice lunga su come stavo messo:

```

s939 ~ # ls -l ar

lrwxrwxrwx 1 root root 12 28 dic 08:34 ar -> /bin/busybox*

```

farò un'analisi di coscienza.

tuttavia, qualcosa ancora non mi torna.

ho rimosso il link e ho ricompilato binutils.

tuttavia, il fantasma permane:

```

s939 ~ # ls -l /usr/bin/ar

lrwxrwxrwx 1 root root 22 29 mag 21:22 /usr/bin/ar -> x86_64-pc-linux-gnu-ar

s939 ~ # qfile /usr/bin/ar

s939 ~ # 

```

----------

## Apetrini

Il fantasma rimarrà sempre li indipendentemente da quante volte ricompili binutils.

A quanto pare questi link sono ricreati dopo il merge, ma non sono "mappati". Non è l'unico esempio di link non mappato...

----------

