Sempre ai fini della corretta installazione di GeoDjango
<http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Installazione-manuale-librerie-proj-su-Ubuntu-18-04-td7598657.html>
, sto riscontrando difficoltà con l'installazione di GDAL.
In particolare mi viene restituito questo messaggio di errore dopo aver
digitato *./configure*:
/checking for PROJ >= 6 library... checking for proj_create_from_wkt in
-lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
configure: error: PROJ 6 symbols not found/
Qui
<https://gis.stackexchange.com/questions/317109/build-gdal-with-proj-version-6>
ho trovato quella che credevo essere la soluzione ma non è così.
Come potrei uscire da questo stallo?
Sono su Ubuntu 18.04 e qui c'è la guida ufficiale alla configurazione di
GeoDjango
<https://docs.djangoproject.com/en/2.2/ref/contrib/gis/install/geolibs/>
-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
On Wed, 12 Jun 2019 03:46:33 -0700 (MST), Massimiliano Moraca wrote:
, sto riscontrando difficoltà con l'installazione di GDAL.
In particolare mi viene restituito questo messaggio di errore dopo aver
digitato *./configure*:
/checking for PROJ >= 6 library... checking for proj_create_from_wkt in
-lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
configure: error: PROJ 6 symbols not found/
Massimiliano,
immagino che sul tuo PC ci fosse gia' installata una precedente
versione della PROJ
quindi molto probabilmente ora che hai fatto la tua build partendo
dai sorgenti ti trovi con _DUE_ diverse versioni della PROJ
installate, quella standard di sistema e la tua custom.
lo script ./configure in genere va sempre a cercarsi le librerie
e gli headers nelle directories standard dei system packages,
e quindi finisce per pescare quelle vecchie che non supportano
le nuov API della PROJ.6, e quindi fallisce.
ma il ./configure della PROJ ti consente di avvisarlo del fatto
che intendi usare una PROJ "fuori standard" in modo tutto sommato
facile e diretto:
./configure --with-proj=/usr/local
giusto nel caso che non funzioni, dovresti verificare se la
tua libreria si trova effettivamente dentro a /usr/local/lib,
mentre gli header files li dovresti trovare dentro a
/usr/local/include
se non li trovi in queste posizioni, la cosa piu' facile e'
immaginare che tu ti sei dimenticato di intallare la PROJ.6
custom dopo averla compilata ... poco male, basta questo
comando per rimediare:
sudo make install
ciao Sandro
Alessandro da terminale riesco a vedere che in usr/local/lib c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/lib$ ls
libgeos-3.7.2.so libgeos_c.so libgeos.so libproj.so.15
python3.6
libgeos.a libgeos_c.so.1 libproj.a libproj.so.15.1.0
libgeos_c.a libgeos_c.so.1.11.2 libproj.la pkgconfig
libgeos_c.la libgeos.la libproj.so python2.7
/
Mentre in usr/local/include c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/include$ ls
geodesic.h geos.h proj_api.h proj.h
geos org_proj4_PJ.h proj_constants.h proj_symbol_rename.h
geos_c.h proj proj_experimental.h/
Vedo che ci sono dei file che fanno riferimento a proj, sono quelli
corretti?
-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
Ho rieseguito il processo di installazione delle proj6 per sicurezza ma
dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di cui
sopra
Il giorno mer 12 giu 2019 alle ore 15:35 Massimiliano Moraca <
massimilianomoraca@gmail.com> ha scritto:
Alessandro da terminale riesco a vedere che in usr/local/lib c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/lib$ ls
libgeos-3.7.2.so libgeos_c.so libgeos.so libproj.so.15
python3.6
libgeos.a libgeos_c.so.1 libproj.a libproj.so.15.1.0
libgeos_c.a libgeos_c.so.1.11.2 libproj.la pkgconfig
libgeos_c.la libgeos.la libproj.so python2.7
/
Mentre in usr/local/include c'è questo:
/(base) maxdragonheart@Drako-U:/usr/local/include$ ls
geodesic.h geos.h proj_api.h proj.h
geos org_proj4_PJ.h proj_constants.h proj_symbol_rename.h
geos_c.h proj proj_experimental.h/
Vedo che ci sono dei file che fanno riferimento a proj, sono quelli
corretti?
-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017
On Wed, 12 Jun 2019 16:03:53 +0200, Massimiliano Moraca wrote:
Ho rieseguito il processo di installazione delle proj6 per sicurezza ma
dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di cui
sopra
ma ora stai chiamando ./configure "liscio" (senza argomenti)
oppure gli stai passando anche la direttiva che lo punta sulla
libreria custom ?
./configure --with-proj=/usr/local
se hai fatto tutto secondo le regole e continua a non funzionare
non ci rimane che ricorrerre alle variabili d'ambiente del gcc,
che in genere risolvono tutti i conflitti quando ci sono piu'
versioni della medesima libreria:
export "CPPFLAGS=-I/usr/local/include"
export "LDFLAGS=-L/usr/local/lib"
./configure --with-proj=/usr/local
microspiegazione: la prima export forza gcc a cercare gli
headers per prima cosa dentro ad /usr/local/include
la seconda forza il linker a cercare le librerie dentro
ad /usr/local/lib con la massima priorita'; solo se non
le trova continuera' poi a cercarle tra i system packages.
ciao Sandro
Noto che l'errore che compivo era scrivere *./configure
--with-proj4=/usr/local* anzicchè *./configure --with-proj=/usr/local *
Ora ho dato *make* e sto aspettando che termini.
Grazie come sempre Alessandro
Il giorno mer 12 giu 2019 alle ore 16:28 <a.furieri@lqt.it> ha scritto:
On Wed, 12 Jun 2019 16:03:53 +0200, Massimiliano Moraca wrote:
> Ho rieseguito il processo di installazione delle proj6 per sicurezza
> ma
> dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di
> cui
> sopra
>
ma ora stai chiamando ./configure "liscio" (senza argomenti)
oppure gli stai passando anche la direttiva che lo punta sulla
libreria custom ?
./configure --with-proj=/usr/local
se hai fatto tutto secondo le regole e continua a non funzionare
non ci rimane che ricorrerre alle variabili d'ambiente del gcc,
che in genere risolvono tutti i conflitti quando ci sono piu'
versioni della medesima libreria:
export "CPPFLAGS=-I/usr/local/include"
export "LDFLAGS=-L/usr/local/lib"
./configure --with-proj=/usr/local
microspiegazione: la prima export forza gcc a cercare gli
headers per prima cosa dentro ad /usr/local/include
la seconda forza il linker a cercare le librerie dentro
ad /usr/local/lib con la massima priorita'; solo se non
le trova continuera' poi a cercarle tra i system packages.
ciao Sandro
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
796 iscritti al 28/12/2017
On Wed, 12 Jun 2019 16:41:39 +0200, Massimiliano Moraca wrote:
Noto che l'errore che compivo era scrivere _./configure
--with-proj4=/usr/local_ anzicchè _./configure
--with-proj=/usr/local _
sugggerimento: e' una caratteristica standard di tutti gli
script ./configure; se tu chiami
./configure --help
ti uscira' fuori un paginone bello lungo con tutte le
possibili opzioni supportate da quello specifico script.
merita sempre leggersele con estrama attenzione, perche'
spesso la soluzione di molti problemi di configurazione
apparentemente insolubili e' nascosta proprio li dentro.
consiglio ancora piu' utile: se ci fai caso ogni volta
che fai girare ./configure ti genera un file che si
chiama config.log, e che ti spiega per filo e per segno
tutto quello che e' stato fatto, inclusi eventuali
errori. anche questo e' fondamentale per capire dove
eventualmente si impiglia.
ciao Sandro
Grazie per i preziosi consigli Sandro.
Vedo che effettivamente ci vuole molto tempo per terminare il make, proprio
come indicato nella procedura sul sito di GeoDjango. Mi sa che solo un
caffè non basta per occupare l'attesa
Il giorno mer 12 giu 2019 alle ore 16:49 <a.furieri@lqt.it> ha scritto:
On Wed, 12 Jun 2019 16:41:39 +0200, Massimiliano Moraca wrote:
> Noto che l'errore che compivo era scrivere _./configure
> --with-proj4=/usr/local_ anzicchè _./configure
> --with-proj=/usr/local _
>
sugggerimento: e' una caratteristica standard di tutti gli
script ./configure; se tu chiami
./configure --help
ti uscira' fuori un paginone bello lungo con tutte le
possibili opzioni supportate da quello specifico script.
merita sempre leggersele con estrama attenzione, perche'
spesso la soluzione di molti problemi di configurazione
apparentemente insolubili e' nascosta proprio li dentro.
consiglio ancora piu' utile: se ci fai caso ogni volta
che fai girare ./configure ti genera un file che si
chiama config.log, e che ti spiega per filo e per segno
tutto quello che e' stato fatto, inclusi eventuali
errori. anche questo e' fondamentale per capire dove
eventualmente si impiglia.
ciao Sandro