Bakit gumagana ang utos na openssl pero nabibigo ang pagbuo ng VPN
Ang gumaganang openssl binary ay walang sinasabi tungkol sa mga header at link library. Suriin ang dev package, arkitekturang target at ang log ng discovery ng build.
Masayang nag-uulat ang terminal ng bersyon ng OpenSSL, at ang source tree ay nabibigo pa rin na may mensahe tungkol sa nawawalang crypto header. Parehong totoo ang dalawang pahayag nang sabay, dahil ang runtime tool at isang set ng build input ay hiwalay na ipinapadala. Gawin ang apat na pagsusuring ito sa pagkakasunod-sunod: mga naka-install na package, output ng discovery, mga search path, at pagkatapos kung ang source mismo ay compatible. Huminto sa unang nagpapaliwanag ng pagpalya sa halip na mag-paste ng lumang listahan ng dependency.
Ang runtime at build input ay magkaibang package
Pinaghihiwalay ng isang distribution ang OpenSSL sa runtime package na nagbibigay ng shared library at command-line tool, at development package na nagbibigay ng header, link name na walang bersyon at pkg-config metadata. Ang pag-install ng una ay hindi nag-iinstall ng pangalawa, at ang compiler ay nangangailangan lamang ng pangalawa.
Suriin kung ano ang tunay na naroroon at hindi kung ano ang natatandaan mong in-install mo. Sa mga sistemang nakabatay sa Debian ang development package ay karaniwang libssl-dev, samantalang ang runtime ay isang versioned library package at ang openssl binary.
dpkg -l | grep -E 'libssl-dev|libssl3|openssl' pkg-config --modversion openssl openssl version
Ang unang command ay nagpapakita kung alin sa tatlo ang naka-install, ang pangalawa ay nag-uulat ng bersyon na matatagpuan ng build system sa pamamagitan ng pkg-config, at ang pangatlo ay nag-uulat ng runtime na bersyon. Ang nawawalang linya sa unang output ay agad na nagpapaliwanag ng error. Ang pagkakaiba ng bersyon sa pagitan ng pangalawa at pangatlo ay ibang problema, at karaniwang nangangahulugan na may dalawang installation na nagtatagisan.
Basahin ang sariling discovery output ng build
Makikita ang karamihan ng pagpalya sa configuration log kung babasahin mo ito bago ang buod. Ang FindOpenSSL module ng CMake ay nag-uulat kung aling include directory at aling mga library ang natagpuan nito, at nabibigo ito nang may partikular na mensahe kapag kulang ang kinakailangang component.
Tiyakin kung aling bersyon ng module ang ginagamit ng proyekto, dahil ang kopyang nakasama sa loob ng source tree ay maaaring kumilos nang iba kaysa sa kasama ng naka-install na CMake. Pagkatapos basahin ang listahan ng component: ang proyektong humihingi lamang ng Crypto ay hindi nangangailangan ng SSL library, at ang humihingi ng SSL ay mabibigo kung bahagi lamang ng development package ang naroroon.
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release grep -i -E 'openssl|ssl' build/CMakeCache.txt
Ang unang command ay muling nagko-configure mula sa simula, at ang pangalawa ay nagpapakita ng mga naka-cache na resulta, kasama ang anumang root directory o library path na napuntahan ng module. Kung ang cache ay tumuturo sa lumang prefix mula sa naunang pagtatangka, burahin ang build directory at muling i-configure sa halip na i-edit ang mga value nang manu-mano. Ang mga lipas na entry sa cache ay karaniwang dahilan ng pagpalyang nananatili kahit may tamang pagwawasto.
Itutok ang build sa tamang installation, nang makitid
Kapag ang aprubadong OpenSSL ay nasa labas ng default na search path, idinodokumento ng FindOpenSSL ang OPENSSL_ROOT_DIR bilang hint para sa partikular na build na iyon. Sa mga sistemang tulad ng Unix ay sumasangguni rin ito sa pkg-config, kaya ang angkop na PKG_CONFIG_PATH ay makatutulong nang walang binabago sa pandaigdigang antas.
cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release ldd build/vpn_client | grep -i ssl
Ang unang command ay nililimitahan ang hint sa isang build directory, at ang pangalawa ay nagpapakita kung aling shared library ang ikakarga ng resultang binary sa runtime. Ang build na naka-link sa nilalayong prefix at binary na nagkakarga ng iba ay problema sa runtime path, hindi problema sa discovery, at nangangailangan ito ng desisyon tungkol sa rpath o configuration ng loader sa halip na isa pang configuration flag.
Panatilihing lokal sa build ang mga pagpipiliang ito. Ang pagpapalit ng system library o pag-edit ng pandaigdigang pkg-config file para masiyahan ang isang proyekto ay ang paraan kung paano nagiging sirâ ang gumaganang desktop. Ang build directory na nagtatala ng prefix ay maaaring muling gawin; ang pagbabago sa buong makina ay insidente sa suporta na naghihintay sa susunod na proyekto. Burahin ang build directory kapag binago mo ang hint, upang hindi maingatan ng cache ang lumang sagot.
Alamin kung kailan ang source ang problema
Ang matagumpay na configuration step ay nagpapatunay lamang na natapos ang mga pagsusuri. Maaari pa ring tanggihan ng compilation ang API na inaasahan ng source, at maaari pa ring mabigo ang linking dahil sa kulang na symbol. Itago ang unang partikular na error mula sa bawat yugto, dahil ang mga sumunod ay karaniwang bunga.
Idineklara ng OpenSSL 3 na luma at inalis ang ilang interface na direktang ginagamit ng mas lumang VPN client, kaya ang source tree mula sa panahong iyon ay maaaring mangailangan ng tunay na pagbabago sa halip na bagong include path. Kung sinusuportahan ng mga maintainer ang kasalukuyang release, gamitin iyon. Kung hindi, ang desisyon ay pag-aari ng may-ari ng serbisyo, hindi ng paghahanap ng mas lumang library file name.
Ang mga opsyonal na desktop component ay may sariling pangangailangan din. Ang command-line target na malinis na nagko-configure ay walang sinasabi tungkol sa kung mabubuo ang GUI toolkit at editor, kaya ituring ang lumang Qt package list bilang kasaysayan at hindi bilang spec. Suriin ang sariling opsyon ng source revision kung aling interface ang naka-enable bilang default. Pagkatapos ay buuin lamang ang kailangan mo, dahil ang bawat opsyonal na dependency ay isa pang problema sa discovery na naghihintay mangyari.