libtoolize - non mette files ausiliari nella dir corrente

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » lun giu 25, 2018 17:54

Ciao a tutti stavo ricompilado i pacchetti SBo che ho sul sistema con il tool sbopkg... Ad un certo punto ottengo un errore durante il build di:

Codice: Seleziona tutto

liblrdf

Codice: Seleziona tutto

LRDF-0.6.1/src/md5.h
libtoolize: putting auxiliary files in '../..'.
libtoolize: linking file '../../ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:5: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.ac:5: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:11: installing './compile'
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:16: error: required file './ltmain.sh' not found
configure.ac:5: installing './missing'
examples/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
automake --add-missing --foreign failed, exiting...
Cleaning up...

liblrdf:
Would you like to continue processing the rest of the
queue or would you like to abort?  If this failed
package is a dependency of another package in the queue
then it may not make sense to continue.   

(Y)es to continue, (N)o to abort, (R)etry the build?: n

Magari non c'entra nulla, ma sul sistema avevo installate due versioni di libtool.
Quella liscia, derivante dalle "patches" del repo ufficiale di slackware 14.2 64 bit.
E quella compat-32 presa dal repo multilib di Alien.

Non so se questa situazione sia corretta, cioè se sia ok averle entrambe o se invece non abbia senso e conviene avere solo quella multilib.
Alla fine nel dubbio ho provato a disinstallare la versione liscia e tenere solo la multilib:

Codice: Seleziona tutto

# slackpkg search libtool                                     


NOTICE: pkglist is older than 24h; you are encouraged to re-run 'slackpkg update'

Looking for libtool in package list. Please wait... DONE

The list below shows all packages with name matching "libtool".

[ Status           ] [ Repository               ] [ Package                                  ]
   installed               multilib                     libtool-compat32-2.4.6-x86_64-5_slack14.2compat32 
  uninstalled              patches                      libtool-2.4.6-x86_64-5_slack14.2         
  uninstalled(masked)      slackware64                  libtool-2.4.6-x86_64-4                   

You can search specific files using "slackpkg file-search file".


Non è che mi sapreste un attimo spiegare se così sia corretto ed eventualmente fosse il caso, perchè averle entrambe sia invece un pasticcio?
Diciamo che il concetto multilib non mi è chiarissimissimo, l'avevo solo messo in pratica per far funzionare i driver della stampante rilasciati solo in 32bit da Brother.

Ad ogni modo ho poi riprovato a compilare liblrdf...
Ma se ne esce così:

Codice: Seleziona tutto

./autogen.sh: riga 10: libtoolize: comando non trovato
libtoolize failed, exiting...
Cleaning up...


In effetti libtoolize c'è ma non è nel PATH, lo trovo in /usr/bin/32
Provando a modificare PATH aggiungendo quel percorso e poi avviando ancora sbopkg ottengo un ulteriore errore:

Codice: Seleziona tutto

LRDF-0.6.1/src/md5.h
libtoolize:   error: $pkgauxdir is not a directory: '/usr/share/libtool/build-aux'
libtoolize failed, exiting...
Cleaning up...

Ma a questo punto prima di ravanare oltre, ho pensato sia meglio chiedere:
- sia se il problema possa dipendere da un ambiente "multilib" non installato a dovere (tipo appunto pacchetti in doppia versione che possano generare casini o altro...)
- sia se invece il problema della compilazione sia dovuto completamente ad altri motivi.
- e già che siamo di strada comunque una sintesi su come vada sistemato l'ambiente multilib mi farebbe molto comodo. (io avevo visto questo: https://docs.slackware.com/slackware:multilib ma mi sfugge qualcosa).

Grazie in anticipo a tutti! :)
Ultima modifica di joe il mar giu 26, 2018 22:41, modificato 1 volta in totale.

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.19.0-rc8
Desktop: lxde
Località: Pisa
Contatta:

Re: Dubbio su multilib

Messaggioda ponce » lun giu 25, 2018 20:26

joe ha scritto:Ciao a tutti stavo ricompilado i pacchetti SBo che ho sul sistema con il tool sbopkg... Ad un certo punto ottengo un errore durante il build di:

Codice: Seleziona tutto

liblrdf

Codice: Seleziona tutto

LRDF-0.6.1/src/md5.h
libtoolize: putting auxiliary files in '../..'.
libtoolize: linking file '../../ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:5: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.ac:5: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:11: installing './compile'
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:16: error: required file './ltmain.sh' not found
configure.ac:5: installing './missing'
examples/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
automake --add-missing --foreign failed, exiting...
Cleaning up...

l'output qui e'

Codice: Seleziona tutto

LRDF-0.6.1/src/md5.h
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
/usr/share/aclocal/libxosd.m4:9: warning: underquoted definition of AM_PATH_LIBXOSD
/usr/share/aclocal/libxosd.m4:9:   run info Automake 'Extending aclocal'
/usr/share/aclocal/libxosd.m4:9:   or see https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
configure.ac:5: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.ac:5: https://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:11: installing './compile'
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
examples/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
Running ./configure ...

mi sembra diverso dal tuo ma non saprei il perche'
- sia se il problema possa dipendere da un ambiente "multilib" non installato a dovere (tipo appunto pacchetti in doppia versione che possano generare casini o altro...)
- sia se invece il problema della compilazione sia dovuto completamente ad altri motivi.

credo la seconda che hai detto, ti conviene reinstallare libtool di Slackware (senza difficilmente ti compilera' qualcosa).

- e già che siamo di strada comunque una sintesi su come vada sistemato l'ambiente multilib mi farebbe molto comodo. (io avevo visto questo: https://docs.slackware.com/slackware:multilib ma mi sfugge qualcosa).

cosa ti sfugge?
come guida il README nella directory tramite cui vengono distribuiti mi e' sempre sembrato sufficiente
http://www.slackware.com/~alien/multilib/

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Dubbio su multilib

Messaggioda joe » lun giu 25, 2018 20:52

Per quanto riguarda multilib, il tuo documento linkato è identico al mio se non sbaglio, solo che uno è in formato "wiki" l'altro in TXT.
Non, la domanda sul multilib era:
le due versioni di libtool possono coesistere sullo stesso sistema o confliggono?
Come vedi adesso le ho entrambe installate, sia quella di default che quella compat32.

Codice: Seleziona tutto

# slackpkg search libtool 


NOTICE: pkglist is older than 24h; you are encouraged to re-run 'slackpkg update'

Looking for libtool in package list. Please wait... DONE

The list below shows all packages with name matching "libtool".

[ Status           ] [ Repository               ] [ Package                                  ]
   installed               multilib                     libtool-compat32-2.4.6-x86_64-5_slack14.2compat32 
   installed               patches                      libtool-2.4.6-x86_64-5_slack14.2         
  uninstalled(masked)      slackware64                  libtool-2.4.6-x86_64-4                   

You can search specific files using "slackpkg file-search file".

Invece per quel che riguarda l'errore di sbopkg nella compilazione di liblrdf, brancolo nel buio...

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.19.0-rc8
Desktop: lxde
Località: Pisa
Contatta:

Re: Dubbio su multilib

Messaggioda ponce » lun giu 25, 2018 22:25

joe ha scritto:le due versioni di libtool possono coesistere sullo stesso sistema o confliggono?

possono coesistere.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Dubbio su multilib

Messaggioda joe » mar giu 26, 2018 12:02

Tu quale versione hai installata?
Quella ufficiale che si trova nelle patches?

Codice: Seleziona tutto

libtool-2.4.6-x86_64-5_slack14.2

Comunque ho provato a mettere anche la versione originaria libtool-2.4.6-x86_64-4, ma qui non cambia nulla.
A parte libtool in se, cosa potrei controllare di altro che magari può essere collegato a quella compilazione fallita?

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.19.0-rc8
Desktop: lxde
Località: Pisa
Contatta:

Re: Dubbio su multilib

Messaggioda ponce » mar giu 26, 2018 12:54

joe ha scritto:Tu quale versione hai installata?
Quella ufficiale che si trova nelle patches?

Codice: Seleziona tutto

libtool-2.4.6-x86_64-5_slack14.2

si, quella.
Comunque ho provato a mettere anche la versione originaria libtool-2.4.6-x86_64-4, ma qui non cambia nulla.
A parte libtool in se, cosa potrei controllare di altro che magari può essere collegato a quella compilazione fallita?

non ho idea.
quello che ho notato e' che i path con cui lavori e dove viene creato il file ltmain.sh sono sbagliati.
nel tuo caso

Codice: Seleziona tutto

libtoolize: putting auxiliary files in '../..'.
libtoolize: linking file '../../ltmain.sh'

e infatti poi l'errore e'

Codice: Seleziona tutto

configure.ac:16: error: required file './ltmain.sh' not found

nel mio invece

Codice: Seleziona tutto

libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'

e la compilazione prosegue.

pero' potresti evitarti mal di pancia facendoti una macchina virtuale con un'installazione completa e pulita e compilare li' i tuoi pacchetti: vale la pena di impazzire dietro ad un'installazione non pulita (e non supportata, aggiungo)? io direi di no.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Dubbio su multilib

Messaggioda joe » mar giu 26, 2018 15:27

La mia installazione non è pulita nel senso che ho aggiunto qualche pacchetto da Alien e altri da SBo, e banalmente li ho aggiunti perchè mi servivano... Cioè non è che mi sono inventato un sistema più di tanto sgaruppato...

Ma lì il problema potrebbe essere piuttosto banale forse... e ripeto forse.
La tua osservazione sul PATH è corretta.
Mi sono andato a vedere il tuo slackbuild (..vedo che sei proprio tu il maintainer dello slackbuild in questione su SBo ;) ), che è quello che usa sbopkg e quindi è quello che viene eseguito.
libtoolize viene invocato dallo script autogen.sh che si trova nel pacchetto stesso di liblrdf.

Vediamo di capire cosa succede.

Codice: Seleziona tutto

TMP=${TMP:-/tmp/SBo}

cd $TMP
tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf $CWD/LRDF-$VERSION.tar.gz
cd LRDF-$VERSION

./autogen.sh

lo script "autogen.sh" viene quindi lanciato dalla direcotry /tmp/SBo/LRDF-0.6.1.
In particolare il comando che fallisce, nel senso che crea il link "ltmain.sh' nella directory "../.." (per poi non trovarlo nella dir corrente) dovrebbe essere il seguente, sbirciando in autogen.sh.

Codice: Seleziona tutto

gprefix=`which glibtoolize 2>&1 > /dev/null`
if [ $? -eq 0 ]; then
  LIBTOOLIZE=glibtoolize
else
  LIBTOOLIZE=libtoolize
fi

$LIBTOOLIZE --force || {
        echo "libtoolize failed, exiting..."
        exit 1
}

Cioè in pratica le operazioni che si fanno sono:

Codice: Seleziona tutto

cd /tmp/SBo
tar liblrdf...z
cd lrdf-0.6.1
libtoolize --force

Il comando libtoolize --force viene quindi lanciato mentre ci si trova in:

Codice: Seleziona tutto

/tmp/SBo/liblrdf-0.6.1

Ho fatto un piccolo test, diciamo così..."brutale". Tanto per vedere cosa succede:

Codice: Seleziona tutto

# cd /tmp
:/tmp# mkdir libtool-test
:/tmp# cd libtool-test/
:/tmp/libtool-test# libtoolize --force
libtoolize: putting auxiliary files in '..'.
libtoolize: linking file '../ltmain.sh'
:/tmp/libtool-test# ls -l ../ltmain.sh
lrwxrwxrwx 1 root root 38 giu 26 14:12 ../ltmain.sh -> /usr/share/libtool/build-aux/ltmain.sh

In pratica libtoolize crea il link non nella dir corrente ma nella parent "..".

Però ho per caso osservato che se si lancia da una sotto directory ulteriore, il link viene generato sempre in "/tmp", quindi non più nella parent ma in "../..".
Guardate un po':

Codice: Seleziona tutto

:/tmp/libtool-test# mkdir pippo
:/tmp/libtool-test# cd pippo
:/tmp/libtool-test/pippo# libtoolize --force
libtoolize: putting auxiliary files in '../..'.
libtoolize: linking file '../../ltmain.sh'

Ma la cosa ancor più incomprensibile è per quale santo se provo a creare un'ulteriore subdir e lancio libtoolize da dentro lì, il link in quel caso viene creato nella dir corrente.

Codice: Seleziona tutto

:/tmp/libtool-test/pippo# mkdir pluto
:/tmp/libtool-test/pippo# cd pluto/
:/tmp/libtool-test/pippo/pluto# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
:/tmp/libtool-test/pippo/pluto# ls -l ltmain.sh
lrwxrwxrwx 1 root root 38 giu 26 14:58 ltmain.sh -> /usr/share/libtool/build-aux/ltmain.sh

E se invece lavorassi dalla home di "root" cioè /root/??

Codice: Seleziona tutto

:~# mkdir libtool-test
:~# cd libtool-test
:~/libtool-test# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
:~/libtool-test# ls -l ltmain.sh
lrwxrwxrwx 1 root root 38 giu 26 15:22 ltmain.sh -> /usr/share/libtool/build-aux/ltmain.sh

In pratica solo lavorando in sottocartelle di /tmp accade il comportamento inaspettato. E neanche sempre, basta lavorare da una ulteriore sottodirectory che il link viene creato nella dir corrente.
Perchè mai questo comportamento di libtoolize, così poco "razionale"?
Francamente mi sembra davvero molto strano.
Ma parlo da ignorante. Magari chi ha dimestichezza con "libtoolize" potrà far luce sulla faccenda.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » mar giu 26, 2018 23:13

Alla fine sono riuscito a compilare il pacchetto "liblrdf".
Ma non sono riuscito a capire perchè lo slackbuild si SBo, manutenuto tra l'altro da Ponce, sul mio sistema fallisca.
Abbiamo capito cosa fallisce di preciso.
Si tratta di "libtoolize", che crea files ausiiliari non nella dir corrente, ma nella dir /tmp.
Perchè si comporti così resta un mistero.
Mi piacerebbe capirlo perchè non vorrei che fosse indice di qualche incasinamento del mio sistema.
Per cui se avete idee in merito dite pure.

Tornando al pacchetto liblrdf ho modificato il file

Codice: Seleziona tutto

configure.ac

In partica vi ho aggiunto una variabile ( AC_CONFIG_AUX_DIR ) che assicura che i files ausiliari vengano creati (linkati) nella dir indicata (nella fattispecie ho messo la dir corrente "."), dove dopo vengono cercati e trovati.
Ecco la patch:

Codice: Seleziona tutto

diff -Naru configure.ac LRDF-0.6.1/configure.ac > configure.ac.patch

Codice: Seleziona tutto

liblrdf# cat configure.ac.patch
--- LRDF-0.6.1/configure.ac     2017-01-09 17:58:58.000000000 +0100
+++ configure.ac        2018-06-26 22:23:39.736214841 +0200
@@ -1,6 +1,7 @@
 # Process this file with autoconf to produce a configure script.
 AC_INIT(src/lrdf.c)
 AC_CONFIG_MACRO_DIR([m4])
+AC_CONFIG_AUX_DIR([.])
 AM_CONFIG_HEADER(config.h)
 AM_INIT_AUTOMAKE(liblrdf, 0.5.0)

Codice: Seleziona tutto

 
liblrdf# ls
README  configure.ac.patch  liblrdf-0.6.1.tar.gz@  liblrdf.SlackBuild*  liblrdf.info  slack-desc

Ho quindi modificato lo slackbuild di ponce, l'ho copiato nel repo locale di SBo, come segue (mostro anche la riga aggiunta per applicare la patch):

Codice: Seleziona tutto

:/tmp/autotools-test/liblrdf# cp liblrdf.SlackBuild /var/lib/sbopkg/SBo/14.2/libraries/liblrdf/liblrdf.SlackBuild.sbopkg                                       
:/tmp/autotools-test/liblrdf# cp configure.ac.patch /var/lib/sbopkg/SBo/14.2/libraries/liblrdf
:/tmp/autotools-test/liblrdf# sbopkg -i "liblrdf"                                                                       
Both a queuefile and a package were found with the name "liblrdf".

Use (Q)ueuefile, (P)ackage, or (A)bort?: p

A local SlackBuild file for liblrdf was found in addition to the original
SlackBuild file.

Use (O)riginal/(L)ocal, see (D)iff, or (C)ancel?: d
--- ./libraries/liblrdf/liblrdf.SlackBuild      2018-02-10 02:14:53.000000000 +0100
+++ ./libraries/liblrdf/liblrdf.SlackBuild.sbopkg       2018-06-26 23:02:14.325371982 +0200
@@ -63,6 +63,7 @@
 rm -rf LRDF-$VERSION
 tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf $CWD/LRDF-$VERSION.tar.gz
 cd LRDF-$VERSION
+patch -p1 < $CWD/configure.ac.patch
 chown -R root:root .
 find -L . \
  \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
Use (O)riginal/(L)ocal, see (D)iff, or (C)ancel?: l

###########################################
       New queue process started on:
       mar 26 giu 2018, 23.02.28, CEST
###########################################

+++++++++++++++++++++++++++++++++++++++++++
PRE-CHECK LOG
Using the SBo repository for Slackware 14.2
Queue Process:  Download, build, and install

liblrdf:
  Checking GPG for liblrdf.tar.gz ... OK
  Processing liblrdf 0.6.1-1
  Using original .info file
  Using local SlackBuild file
  No build options selected.

+++++++++++++++++++++++++++++++++++++++++++

Pre-check complete.

Do you wish to proceed based on the search results above? Packages not
found will be skipped during the process.

(P)roceed or (Q)uit?: p

Insomma, così funziona...
Ho scritto il tutto principalmente per mia memoria, così un domani eventualmente so dove cercare.
È ovvio, ripeto che è una pezza, nel senso che ci deve essere un motivo per cui libtool si comporta così da me, mentre come diceva ponce, a lui non risulta questo strano comportamento. Tutto sommato comunque funziona.
Se vi viene in mente qualche motivo per cui libtoolize fa così, dite pure! ;)

Avatar utente
conraid
Staff
Staff
Messaggi: 13221
Iscritto il: gio lug 14, 2005 0:00
Nome Cognome: Corrado Franco
Slackware: current64
Località: Livorno
Contatta:

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda conraid » mer giu 27, 2018 11:25

C'è qualcosa di errato nel tuo sistema, in una installazione pulita funziona così

root@chroot:/tmp/prova# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'


Crea il link simbolico nella stessa directory, e sei fai subdir lo crea in essa.
Stessa cosa in una installazione "sporca".

E stessa cosa con LDRF

Codice: Seleziona tutto

conraid@blankstar:/tmp/prova/LRDF-0.6.1$ libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'


p.s.
io sono in -current 64 bit

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » mer giu 27, 2018 12:06

Grazie ad entrambi per la verifica.
Ho provato a chiedere anche su LQ, vediamo anche lì se magari qualcuno ha qualche idea di cosa possa aver incasinato sul mio sistema...
In rete ho trovato qualcosa di simile ma sembra un bug probabilmente aggiustato e piuttosto vecchio tra l'altro, inoltre si trattava di debian se non ricordo male.
Se avete idee su cosa possa andare a verificare, sono tutt'orecchi.
Grazie ancora

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » mer giu 27, 2018 15:53

Ok, svelato l'arcano.

La presenza in "/tmp" di un file chiamato "install.sh", compromette il funzionamento atteso di libtoolize nella sottocartella di /tmp (tmp/pippo ad esempio) o in una seconda sotto-cartella (/tmp/pippo/pluto ad esempio).
Non so, se volete anche voi provare il check è facilissimo.
Test a parte questo strano comportamento di libtoolize, manda a donnine l'intero tool sbopkg per quel che riguarda i pacchetti che coinvolgono libtoolize, dal momento che lavora i sorgenti in "/tmp/SBo/nome-programma".
Nella mia esperienza dei giorni scorsi, siccome sto ricompilando l'intero parco software che avevo installato da SBo (circa 255 pacchetti), mi sono imbattuto in questo problema per due volte: come vi avevo detto per "liblrdf" e poco fa per il pacchetto "belle-sip".

Grazie all'utente "orbea" su LQ, che era incappato nello stesso problema, ho verificato la presenza di un file piuttosto anonimo, chiamato appunto install.sh e collocato proprio in /tmp.
Rimosso quel file libtoolize ha funzionato come mi avete descritto voi, creando cioè i file ausiliari nella dir corrente piuttosto che nella parent o gran parent "/tmp".
Non so come l'abbia capito l'amico di LQ, ma a me pare gran bel bug di libtoolize.

Non so se sia il caso di avvertire chi sviluppa quel tool, oppure chi si occupa di sbopkg in modo da patchare i "configure.ac" specificando la variabile "AC_CONFIG_AUX_DIR([.])".
Cosa ne dite?

Fate sapere se riscontrate anche voi il problema... creando un file (penso vada bene anche vuoto) chiamato "install.sh" e lanciando libtoolize --force in una subdir o sub-subdir.

PS.
nel mio caso il file install.sh era il seguente:

Codice: Seleziona tutto

#!/usr/bin/env bash

cd "$(dirname "$0")/app"

which node 2>/dev/null
isNode=$?
echo NodeJS status = $isNode

if [ $isNode -eq 0 ]; then
  node -e "process.exit(Number(process.version.substr(1).split('.')[0]) > 5 ? 0 : 1)"
  isNode=$?
fi
if [ $isNode -eq 0 ]; then
  echo "Installer is using your system NodeJS."
  node install.js `which node` $1
else
  MACHINE_TYPE=`uname -m`
  echo "Installer is using the attached NodeJS"
  if [ ${MACHINE_TYPE} == 'x86_64' ]; then
    ../node/x64/node install.js --add_node $1
  else
    ../node/x86/node install.js --add_node $1
  fi
fi

Sarà il rimasuglio di qualche cosa di poca importanza...

Avatar utente
conraid
Staff
Staff
Messaggi: 13221
Iscritto il: gio lug 14, 2005 0:00
Nome Cognome: Corrado Franco
Slackware: current64
Località: Livorno
Contatta:

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda conraid » mer giu 27, 2018 16:04

Non proprio così. Facendo un debug viene fuori questo

Codice: Seleziona tutto

+ test -f ./install-sh
+ test -f ./install.sh
+ for _G_dir in . .. ../..
+ test -f ../install-sh
+ test -f ../install.sh
+ for _G_dir in . .. ../..
+ test -f ../../install-sh
+ test -f ../../install.sh


quindi non prende install.sh in /tmp, ma install.sh in ., .. e ../..

e infatti con install.sh in /tmp

Codice: Seleziona tutto

conraid@blankstar:/tmp/prova$ libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
conraid@blankstar:/tmp/prova$ cd ..
conraid@blankstar:/tmp$ touch install.sh
conraid@blankstar:/tmp$ cd prova/
conraid@blankstar:/tmp/prova$ libtoolize --force
libtoolize: putting auxiliary files in '..'.
libtoolize: linking file '../ltmain.sh'
conraid@blankstar:/tmp/prova$ mkdir prova
conraid@blankstar:/tmp/prova$ cd prova/
conraid@blankstar:/tmp/prova/prova$ libtoolize --force
libtoolize: putting auxiliary files in '../..'.
libtoolize: linking file '../../ltmain.sh'
conraid@blankstar:/tmp/prova/prova$ mkdir prova
conraid@blankstar:/tmp/prova/prova$ cd prova/
conraid@blankstar:/tmp/prova/prova/prova$ libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'


alla terza subdir funziona normalmente.
E funziona normalmente anche mettendo un install.sh in una qualsiasi delle directory di cui sopra.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » mer giu 27, 2018 16:37

Sì giusto, sei stato più preciso di me, intendevo la stessa cosa ( a parte che vedo che farebbe lo stesso se trovasse anche un file nominato install-sh, cioè col trattino invece che col punto).
Ok, infatti anche l'utente orbea di LQ ha aggiunto questo commento:
https://www.linuxquestions.org/question ... ost5872511

Quindi è un tentativo "euristico" di libtoolize per capire dove piazzare i suoi file ausiliari o almeno il file ltman.sh.
Cioè, è un comportamento voluto, non un bug.
Però si rivela come bug dal momento che compromette ad esempio "sbopkg"...

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2496
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 4.19.0-rc8
Desktop: lxde
Località: Pisa
Contatta:

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda ponce » mer giu 27, 2018 18:44

comunque, per come la vedo io, questa e' la conferma che se tu partissi a compilare quello che ti serve da un'installazione pulita (eh si, anche /tmp/!) non avresti problemi. ;)

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: libtoolize - non mette files ausiliari nella dir corrente

Messaggioda joe » mer giu 27, 2018 19:52

Beh sicuramente la compilazione funzionerebbe con maggiore probabilità, senza problemi e se qualcosa non andasse avrei anche da voi un confronto tra sistemi "standard".
Però io vorrei far girare i programmi sul mio sistema attuale...

Voglio dire, se compilo in ambiente pulito, poi c'è la possibilità che installando il pacchetto sul mio sistema "sporco", questo richieda qualcosa che qui non c'è, perchè magari presente ma in versione non standard, non so se mi sono spiegato...
I grattacapi sarebbero solo rimandati nel caso di un eventuale pacchetto compilato senza problemi in ambiente pulito, ma non funzionante come dovrebbe una volta installato sul sistema reale, non standard.
Al netto di questo aggiungo che installare tutto un ambiente pulito richiede un po' di spazio che dovrei ricavare in qualche modo spostando parecchia roba... Ma ok questo è l'ultimo dei problemi...

Il fatto poi, che un'installazione pulita preveda la directory /tmp vuota e immacolata, bè mi sembra un po' estremo. A quel punto vedo più plausibile interpretare il comportamento di libtoolize al limite del bug.
Cioè se basta un "touch /tmp/install.sh" per mandare a bagno sbopkg o qualsiasi cosa di altro che richieda di far girare libtoolize in una subdir di /tmp allora dal punto di vista "robustezza" siamo messi maluccio (altro che tentativi euristici di capire dove piazzare i files ausiliari).
Non sembra un problemino anche a voi?