curl: (48) Une option inconnue a été transmise à libcurl
C'est vraiment frustrant. Je continue à avoir cette erreur en essayant d'exécuter une commande curl standard:
curl --url https://install.meteor.com | sh
curl: (48) An unknown option was passed in to libcurl
Quelqu'un sait comment réparer ça?
Je viens de rencontrer ce problème moi-même. Un peu de recherche superficielle m'a conduit à cette entrée de traqueur de bogues , mais la mise à jour n'a pas suffi. J'ai récemment construit la version la plus récente de libcurl à partir des sources, alors je me suis dit que cela devait être dû à la confusion dans la structure des répertoires. Je suis sûr que vous n'êtes probablement pas dans la même situation, mais peut-être que Mountain Lion a introduit une erreur assez similaire pour que les mesures que j'ai prises pour résoudre le problème puissent vous aider.
Tout d’abord, lancez which curl pour déterminer d’où l’appel du binaire. Assurez-vous ensuite que cet emplacement existe réellement en exécutant locate -r /curl$. Si ce n'est pas le cas (c'est le problème dans mon cas), essayez d'exécuter curl en utilisant tous les chemins complets fournis par locate, en ignorant ceux qui sont manifestement superflus, comme python-pycurl.
Une fois que vous en avez trouvé un qui fonctionne, vous pouvez soit créer un lien symbolique à partir de celui which trouvé, soit vérifier si le fait de supprimer ce dernier permet au Shell de trouver le correct lui-même. Pour moi, le correctif était aussi simple que de supprimer /usr/local/bin/curl, obligeant which curl à répondre correctement avec /usr/bin/curl et curl pour revenir au fonctionnement normal.
Je viens d'avoir ce problème avec Alpine Linux.
Le correctif était d'installer curl-dev en plus de curl.
Il est fort probable que vous ayez une curl plus récente qui utilise une libcurl plus ancienne qui ne connaît pas une ou plusieurs options que curl essaie d'utiliser.
curl -V montrera ceci et ldd [path to curl] vous montrera toutes les utilisations de bibliothèques partagées par Curl.
C’est la même erreur que je recevais après l’installation de cURL à partir de la source sur Ubuntu.
$ curl http://www.google.com
curl: (48) An unknown option was passed in to libcurl
L'examen de la version de cURL montre que curl a été mis à jour mais utilise l'ancienne version de libcurl:
$ curl --version
curl 7.41.0 (x86_64-unknown-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Pour résoudre mon problème, j'ai copié libcurl.so et les autres à partir du dernier dossier curl que j'ai téléchargé et écrasé ceux déjà installés sur ma machine.
cp /tmp/curl-7.41.0/lib/.libs/libcurl.so* /usr/local/lib/
Cela a résolu mon problème.
$ curl --version
curl 7.41.0 (x86_64-unknown-linux-gnu) libcurl/7.41.0 OpenSSL/1.0.1 zlib/1.2.3.4
$ curl -I http://www.google.com
HTTP/1.1 302 Found
[...snip...]
Si vous venez de créer votre curl à partir des sources, exécutez Sudo ldconfig pour le réparer.
Cela peut être corrigé en réinstallant cURL dans/usr/bin au lieu de/usr/local/bin car Ubuntu 12.04 se comporte de manière étrange lorsque vous installez à des endroits différents.
En outre, cela peut être un correctif possible, mais soyez prudent
ln -s /usr/bin/curl /usr/local/bin/curl
Cela signifie que le binaire dans /usr/local/bin n'est pas vraiment celui que le système recherche, est obsolète ou ne peut pas fonctionner correctement. Un simple lien symbolique est requis.
Pour être en sécurité, vous pourriez aussi bien
mv /usr/local/bin/curl /usr/local/bin/curl.bak
avant ln -s- la version /usr/bin/curl est terminée.
J'ai eu un problème similaire (dans Ubuntu 12.04). J'ai installé manuellement curl dans usr/local/bin et toute commande que je tapais donnait curl:(48) An unknown option was passed in to libcurl
Je l'ai corrigé en désinstallant curl (Sudo make uninstall) et en l'installant depuis apt-get (Sudo apt-get install curl), qui plaçait automatiquement curl dans usr/bin. Ensuite cela a fonctionné!
J'ai également eu cette erreur, mais je ne fais pas fonctionner Mountain Lion, et je voulais un moyen simple et propre de bien faire les choses, à coup sûr - sur n'importe quel système. (Remarque n ° 1: je me trouve dans un chroot Ubuntu/LXDE crouton sur un ancien Chromebook ARMv7.) (Remarque n ° 2: J'ai construit la version nocturne à partir de la source. Je n'ai eu aucun problème à installer curl de manière traditionnelle, à savoir Sudo apt-get install curl. )
Lorsque j'ai vérifié la version curl -V, elle a montré ma nouvelle version de construction nocturne pour curl: 7.51.1-20161107, mais une ancienne libcurl: 7.22 ...
J'avais l'intuition que c'était le problème. J'ai essayé de déconner avec des liens symboliques, mais cela ne fonctionnait pas et je faisais juste un bazar, j'ai donc consulté la page d'installation officielle: https://curl.haxx.se/docs/install.html .
Pour forcer la compilation d'une bibliothèque statique, désactivez la création de la bibliothèque partagée En exécutant configure comme suit:
./configure --disable-shared
J'ai donc lancé ce qui suit à partir de mon répertoire source Curl:
Sudo make uninstall./configure --disable-sharedmakeSudo make install
Maintenant, la version curl correspond à la version libcurl, et cela fonctionne.
J'ai rencontré le même problème sur cygwin, lorsque j'ai construit manuellement curl pour fonctionner avec https et que tout fonctionnait correctement.
jusqu'au jour où j'ai mis à jour le paquet curl en exécutant cygwin setup sans mettre à jour le paquet libcurl4, j'ai commencé à avoir la même erreur.
J'ai vérifié les informations de version de curl en exécutant:
$ curl -V
curl 7.54.1 (i686-pc-cygwin) libcurl/7.52.1 OpenSSL/1.0.2j zlib/1.2.8 libidn2/2.0.2 libpsl/0.17.0 (+libidn2/0.11) libssh2/1.7.0 nghttp2/1.14.0
Release-Date: 2017-06-14
Protocols: dict file ftp ftps Gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: Debug IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy Metalink PSL
J'ai donc trouvé que cygwin a mis à jour le paquet curl en 7.54.1 mais libcurl était toujours à 7.52.1
J'ai donc désinstallé les paquets curl et libcurl et réinstallé, puis tout fonctionnait à nouveau correctement.
$ apt-cyg remove libcurl4 curl
Removing libcurl4
Package libcurl4 removed
Removing curl
Package curl removed
apt-cyg install curl libcurl4
Installing curl
curl-7.54.1-1.tar.xz: OK
Unpacking...
Package curl requires the following packages, installing:
cygwin libcurl4 libmetalink3 libopenssl100 zlib0
Package cygwin is already installed, skipping
Installing libcurl4
libcurl4-7.54.1-1.tar.xz: OK
Unpacking...
Package libcurl4 requires the following packages, installing:
ca-certificates cygwin libgcc1 libgssapi_krb5_2 libidn2_0 libnghttp2_14 libopenldap2_4_2 libopenssl100 libpsl5 libssh2_1 zlib0
Package ca-certificates is already installed, skipping
Package cygwin is already installed, skipping
Package libgcc1 is already installed, skipping
Package libgssapi_krb5_2 is already installed, skipping
Package libidn2_0 is already installed, skipping
Package libnghttp2_14 is already installed, skipping
Package libopenldap2_4_2 is already installed, skipping
Package libopenssl100 is already installed, skipping
Package libpsl5 is already installed, skipping
Package libssh2_1 is already installed, skipping
Package zlib0 is already installed, skipping
Package libmetalink3 is already installed, skipping
Package libopenssl100 is already installed, skipping
Package zlib0 is already installed, skipping
Package curl installed
Package libcurl4 is already installed, skipping
Vérifié à nouveau les informations de version curl:
$ curl -V
curl 7.54.1 (i686-pc-cygwin) libcurl/7.54.1 OpenSSL/1.0.2j zlib/1.2.8 libidn2/2.0.2 libpsl/0.17.0 (+libidn2/0.11) libssh2/1.7.0 nghttp2/1.14.0
Release-Date: 2017-06-14
Protocols: dict file ftp ftps Gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy Metalink PSL
Sur Ubuntu 16.04 LTS, je viens d'ajouter/usr/local/lib à LD_LIBRARY_PATH dans/etc/profile (LD_LIBRARY_PATH =/usr/local/lib: $ LD_LIBRARY_PATH; export LD_LIBRARY_PATH)
Nous avons eu le même problème après avoir compilé à partir de la source sur une installation empaquetée, résolu avec les indicateurs corrects avec configure:
./configure --prefix=/usr --libdir=/usr/lib64
Sans l'option --libdir=, le mien installait une version mise à jour de libcurl dans /usr/lib au lieu de /usr/lib64 et le nouveau binaire curl accédait toujours aux anciennes bibliothèques, ce qui entraînait une incompatibilité.