Fordítás (GNU és egyéb) - 2

Fórumok

Ugyanaz, mint az előző ilyen című topik, csak az már túl nagyra hízott, ezért újat kezdtem.

Hozzászólások

Off: Miért nem blog, ha már blogként írod?

Az élet igazolni akarta előző megérzésemet, miszerint nem valami szerencsés olyasmiket belehardkódolni az exébe, hogy 'PATH=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2' SHOBJ='libgcc_s.a'... ugyanis új gcc verziót telepítettünk, és most az újrainduláskor nem indult, aminek kellett volna...
(Persze akkor sem lett volna jobb, ha az lett volna benne, hogy 'SHOBJ=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2/libgcc_s.a', hiszen a kedves rpm az update alkalmából leszedi a régi, feleslegessé vált libgcc_s.a-t.)

Note to self: az 'ar'-nak linuxon nincs -X32/-X64 opciója... (bár van egy -X32_64, ami egyben alapértelmezés is)

Szerk: 'nm'-re ugyanez igaz

Szerk: és itt külön van a /lib64 meg /usr/lib64

Emlékeztető magamnak: nyomozni kellene, miért lett az openssl-1.0.1-ből openssl.so.1.0.0?

Persze nem akkora baj ez, amit a sed ne tudna javítani...

Szerk:
Persze értem, hogy jót akarnak, meg sok a különféle rendszer; meg az ózonlyuk és a savas eső... olyasmit akarnak mondani, hogy 1.0.0*-tól az 1.0 lesz a 'major', a 0 a minor, és a '*' (betű) pedig csak úgy ottan van, ehhez képest a Makefile-ban ez van:

VERSION=1.0.1c
MAJOR=1
MINOR=0.1
SHLIB_VERSION_NUMBER=1.0.0
SHLIB_MAJOR=1
SHLIB_MINOR=0.0

Az én egybites agyam szerint az alábbi kettő valamelyik kellene legyen:

#1: régi meglátás: minden verzió különbözik

VERSION=1.0.1c
MAJOR=1.0.1
MINOR=
SHLIB_VERSION_NUMBER=1.0.1
SHLIB_MAJOR=1.0.1
SHLIB_MINOR=

#1: új meglátás: az utolsó számjegy kis változást jelent:

VERSION=1.0.1c
MAJOR=1.0
MINOR=1
SHLIB_VERSION_NUMBER=1.0.1
SHLIB_MAJOR=1.0
SHLIB_MINOR=1

Nem.

Azert van kulon valasztva az shlib version, mert maga a frissites olyan osztott konyvtarat eredmenyez, mely szabadon felcserelheto a korabbi, 1.0.0-s verzioju shlibbel, ugyanis mind API, mind pedig ABI szinten kompatibilis, csak mukodes tekinteteben valtozott, felulet tekinteteben nem. Ezert nem szoktak osztott konyvtarnal az utolso szamot surun valtoztatni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A 'file' nevű komponenst említettem a múltkor, annak meg az a trükkje, hogy használná az 'asprintf'-ben a '%zu' szekvenciát; de mivel az AIX-nek nincs ilyen asprintf-je, hát a saját hozott asprintf-jét használja. Amelyik nem ismeri a '%zu'-t. Jajjanyám.

Javítottam "%lu"-ra, így már jobban kijön a hiba:

# file /usr/local/lib64/libcpotlas.so.1.0.2
/usr/local/lib64/libcpotlas.so.1.0.2: ERROR: cannot allocate 0 bytes (Invalid argument)

Ne is kérdezzem, hogy minek neki nulla bájt, igaz?

Szerencsére erre már egyszer hackoltam megoldást (local_malloc és társai: size=0 esetén egy spéci címet adnak vissza), most sokkal jobb: core dump...

Ja, és az openssl-nek (illetve a licryptonak) kell a libz.so
Persze ez csak futáskor derül ki: dlopen-t hív, ha az megtalálja valahol (path nincs -- security?), akkor jó, egyébként nem.

Kieg: az nem segít, ha hozzászerkesztjük az executable-hoz a libz.so-t.

Kieg: a forrásban kommentként benne van, hogy a Windows kedvéért csinálja dlopen-nel (illetve LoadLibrary-val, de ez most mindegy),hogy akkor is menjen, ha nincs zlib.dll

openssl-ről szólva: lehet, hogy arra gondoltak, hogy az 1.0.1 kompatibilis az 1.0.0-lal, ezért jó lesz, ha a major verzió-t 1.0.0-ra állítják.
Ahogy én látom, ugyanezt a múltban ragadt, korszerűtlen keményvonalas linuxosok úgy csinálták volna, hogy csak az 1.0-t nevezik major verziónak, a végén lévő 1-et pedig minor-nak.

readelf -d libcrypto.so.1.0.1
0x0000000e (SONAME)                     Library soname: [libcrypto.so.1.0.0]

Mint például a libz.so.1.2.3.4-ben az 1 a major, a 2.3.4 a minor (érdekes egy verziószám egyébként;)

readelf -d libz.so.1.2.3.4 
 0x0000000e (SONAME)                    Library soname: [libz.so.1]

vl írta 2011. október 4-én ('install' működésére):

> > Szóval inkább én szépen másolom, ha az nem megy,
> > akkor törlöm+létrehozom (törölni akkor is lehet, ha busy).

> Inkább temp, generált néven ugyanabba a könyvtárba létrehozni + rename.

> - nem fordulhat elő, hogy a törlés után nem tudod megcsinálni a fájlt
> - egyetlen mikroszekundumig sem lesz olyan állapot, amikor nincs ott a fájl

Nagyon jó meglátás, azzal a kiegészítéssel, hogy egy library esetén eleve meg sem szabad próbálni az open-t (outputra), mert az AIX-szal szemben a linux nem ad ETEXTBUSY-t, hanem engedi felülírni a shared-libet, akkor is, ha használatban van -- csak éppen a használó programok döglenek ki...

Az új linux rendszerem (Debian-6) azzal a jó hírrel fogadott, hogy az 'rpm -bb' megszűnt működni, ott az 'rpmbuild'... Ugye nem is kell mondanom, hogy az AIX-en lévő régebbi rpm-hez nincs ilyen rpmbuild... Mennyire megkönnyítik az ilyen inkompatibilis felesztések a scriptek készítését!

Ilyesmi, csak az rpmbuild még 'fejlettebb' is, más szóval nem egészen sikerült még működésre bírni... (még a végén visszateszek egy korábbi rpm-et az előző verzióból)

Viszont hasonló módszerrel alkottam egy 'hostname-f' programot, ami linuxon 'hostname -f' -et hívja, AIX-on meg a resolv.conf-ból veszi ki a domaint.

" AIX-on meg a resolv.conf-ból veszi ki a domaint."

Csakhogy ez igy nem korrekt.

A hostname -f linuxon azt csinalja, hogy a hosts fajlban keresi meg a gepen levo ip-khez torteno elso matchelot, es a megfelelo entrynel addig nyalja a gepneveket, amig olyat nem talal, ami ugy kezdodik, mint a gepnev.

C-ben ez egyszerubb, ha elo tudod szedni a gepen levo osszes IP-t, akkor gethostbyaddr() -ral lekered, es vegigszaladsz a h_alias tombon (asszem ez a neve) egy strncmp-vel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A linux-os hostname nem fordul AIX-en, mivel a linux-specifikus ifaddr.h -t használja...
gondolom, az kb hasonlókat tud, mint a net/if, csak legalább nem hordozható...

Egyébként régen a hostname a coreutils része volt, csakis emiatt fordítottam a legújabb coreutils-t (gmp-vel együtt, amihez a libtool-t is haxolnom kellett), azután örömmel láttam, hogy a 'hostname' maradt a régi.

Most hallom, hogy valaki xlc-vel fordít/szerkeszt... ez persze az ő szomorú magánügye, de most összehasonlításképp jó lenne tudnom, hogy mi ott a -Wl,-bmap:mapfile megfelelője. (Vagyis átadni a linkernek némi opciókat.)

Szerk: ájulat! A doksi szerint ugyanúgy!

aix-libtool-ban 5648 sor körül járunk, és lassan megérik a béta-tesztre.

Csak a napló kedvéért: most untam meg, hogy nincs 'diff -u', most következik a GNU diffutils telepítésbe. (Persze forrásból, naná)

Az apache-2.4.3 alkalmából ismét egy kis javítás/szépítés: igenis vannak olyan helyzetek, amikor nincs 'lib' a shared object előtt, pl a mod_cache_disk.so használja a mod_cache.so-t.

---

Persze a régi PHP nem megy az új Apache-csal...

Syntax error on line 235 of /usr/local/etc/apache2/httpd.conf:
Cannot load libexec/apache2/libphp5.so into server:
0509-130 Symbol resolution failed for /usr/local/libexec/apache2/libphp5.so because:
0509-136 Symbol ap_log_error (number 1057) is not exported from dependent module httpd.
0509-136 Symbol ap_log_rerror (number 1058) is not exported from ependent module httpd.
0509-136 Symbol ap_get_server_version (number 1068) is not exported from dependent module httpd.
0509-136 Symbol unixd_config (number 1076) is not exported from dependent module httpd.
0509-192 Examine .loader section symbols with the 'dump -Tv' command.

---

Hasonló nevű szimbólumok persze vannak, pl:
ap_log_error_
ap_log_rerror_
ap_get_server_revision
ap_unixd_config

Gondolom, ennyi változás belefér a verzióváltás szabadságába... vagy mibe...

---

Most éppen a php-5.3.13 újrafordítása sem megy a "meta_ccld" hiánya miatt. (Én még a létezéséről sem tudtam, most meg a hiányával kell szembesülnöm...)

---

Ami egyébként van -- vajon melyik komponens nem találja, és miért nem találja?!

---

Én nem találom. Mármint az én libtoolom. A program nevét vizsgálom, hiszen az opciók értelmezése attól függ.

---

Nyomozásom szerint ez azt jelentheti, hogy valahogy(?) érvényre jutott a --enable-maintainer-zts opció a ./configure során... Az ilyesmi megesik...

---

Nem segített a --disable-maintainer-zts sem. Akkor az UFÓK lehetnek a hibásak.

---

Vagy a szerver verziószáma (aszerint ágazik el a ./configure egy ponton):

$ httpd -v
Server version: Apache/2.4.3 (Unix)

Mai utolsó üzenet:

Syntax error on line 271 of /usr/local/etc/apache2/httpd.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration

Az van ott, hogy "User www-data"... ezzel vajon mi a gond?

No, van új pipacs Apache, multithread és multiprocess közül lehet választani, egyelőre multithread-dal megyünk (mpm_worker), de ha valami gyanús jelet látok, visszamegyünk a régi üzemmódba (mpm_prefork).

Erre a nagy örömre most a PHP-5.4.6 intett be: https://bugs.php.net/bug.php?id=63017

holnaptól innen folyt köv

(PS: dtelnet-1.2.7 érdekel valakit? Nem? Gondoltam.)

Az új PHP első eredménye: htmlspecialchars harmadik paraméterének változott az alapértelmezése. Bővebben itt:

Ékezetes FAQ

Ja és egyes configurék ilyeneket írnak ki:

checking for working fcntl.h... no (bad O_NOATIME, O_NOFOLLOW)

Ki kellene vizsálni ezt is...

Még azt mondja meg valaki, hogy a libstdc++ -szal csak akartam valamit kezdeni, vagy csak erősen rágondoltam, és nem csináltam vele semmit -- legalábbis most, úgy látom, nem megy.

Na szóval aljas módon a libstdc++.so-t is kirángattam békés fészkéből (értsd: tartalmazó .a fájljából), és besymlinkeltem a /usr/local/lib-be. A .la fájlt kicsit meg kellett haxolnom, de most valamennyire megy:

$ dump -H hello

0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/lib                libgcc_s.a          shr.o
2      /usr/local/lib                libstdc++.so.6
3      /usr/local/lib                libcpotlas.so.1
4      /usr/lib                      libc.a              shr.o

És még mindig hátra lenne az a feature, hogy .la fájl nélkül is menjen a verziókezelés (házi feladat magamnak), vagyis ha megtalálja a libstdc++.so -t, és látja rajta, hogy az symlink, akkor a target alapján (libstdc++.so.6.0.16) megpróbálja meghatározni a major verziószámot, magyarul: keres egy libstdc++.so.6 vagy libstdc++.so.6.0 nevű linket, aki ugyanarra a targetre mutat (az előbbit fogja megtalálni), és azt használja a linkeléshez).

Azt olvasom, hogy 7.x-ben már van dirfd. Ez egy másik megfogalmazása annak, hogy 5.x-ben és 6.x-ben nincs.

Azt mondják ugyanis, hogy a readdir_r előtt egy name_max = fpathconf (dirfd (dir), _PC_NAME_MAX) az igazán kúlos, kevésbé menő a name_max = pathconf (dir, _PC_NAME_MAX) -- ugyanis a dir az változhat is (vö: multitaszk, symlink, stb), akár meg is lehet haxorizálni a programot ilyen módon.

Most már ott tartok, hogy linux-ra is meg akarom csinálni a libtool-t... borzasztó, hogy önnön-magamnak generálom a feladatot;)

Most éppen a -Wl,-rpath,uninstalled-la-dir/.libs-et tettem bele, eddig jó is, de egyben észrevettem, hogy a -R opció még nem megy

Következő kötözködés (m4 fordítása):

checking whether rename honors trailing slash on destination... no
checking whether rename honors trailing slash on source... no

Szerintem ez valakinek a fixa ideája, hogy poénból felesleges perjeleket tesz a nevek végére, és ellenőrzi, hogy kap-e hibaüzenetet a különféle rendszerhívásoktól...

Megoldva. Ugyanő:

checking whether rename manages hard links correctly... no
checking whether rename manages existing destinations correctly... no

Az egyik arra céloz (talán), hogy ez nem teljesül:
"If oldpath and newpath are existing hard links referring to the same file, then rename() does nothing, and returns a success status."

Szerk: Na jó, ez én voltam: a 'local_rename' a 'local_symlink'-ből keletkezett (igen, copy+paste fejlesztés), és egy ponton bizony 'symlink' maradt benne 'rename' helyett. Ciki.

Hát, pl a "ls -l etc" és "ls -l etc/" működhet különbözőképpen, ha mondjuk az "./etc" egy könyvtárra mutató symlink.

Itt viszont arról van szó, hogy az alábbi parancs nem megy linuxon (ENOTDIR), de működik AIX-en (és ez valakinek az érzékenységét sérti):

cat /etc/motd/

Most értesültem róla, hogy a gcc-nek van egy -v opciója, ami nagyon hasznos lehet, hogy megtudjuk, mi is történik a háttérben. Pl:

(legyen $GPATH=/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2 mert rengetegszer ismétlődik)

collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o executable /lib/crt0.o -L$GPATH -L$GPATH/../../.. -brtl -bnortllib -bernotok -bipath -bmap:executable.map ... /usr/lib/librt.a /usr/lib/libc.a $GPATH/libgcc.a $GPATH/libgcc_eh.a -lg -lc $GPATH/libgcc.a $GPATH/libgcc_eh.a

(dőltbetűvel van, amit én adok meg, a többit ő teszi hozzá)

Senki sem érezte feladatának, hogy engem tájékoztasson erről az opcióról;)
(A legutóbbi ilyen felfedezésem a -mtune=native volt: hátha a gcc is ki tudja találni, hogy pontosan milyen az aktuális CPU, és nem nekem kell belevasalnom a Makefile-okba egy platformfüggő információt)

Akkor meg par kis hasznos:


$ gcc -v 
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 
$ gcc -dumpmachine
x86_64-linux-gnu
$ gcc -dumpspecs # Itt nincs dump, ez a gcc komplett konfigjat tolja ki

--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

1

Csak arra gondolta, hogy
- mondhatna mondjuk fordítási (mármint amikor a clang-ot fordították) beállításokat
- ha már igyekszik minden gcc opciót ésszel értelmezni, erre is szebb lenne annyi, hogy "Sorry, ez értelmetlen a clang-ban", mint az, hogy "unsupported option"

Ilyen már volt egyszer, de most nem találom...

Pro*C üzeni:

Error at line 148, column 2 in file /usr/include/standards.h
#warning The -qdfp option is required to process DFP code in headers.

Ja igen, ez lett a megoldás a standards.h- ban:

/* itt valami nagyon izgalmas dolog történik, aminek
kb annyi a lényege, hogy összezavarja a Pro*C-t

#if (defined(__IBMC__) || defined(__IBMCPP__))
#if ((defined(__STDC_WANT_DEC_FP__)) && !(defined(__IBM_DFP__)))
#if defined(__IBM_PP_WARNING)
#warning The -qdfp option is required to process DFP code in headers.
#else
#error The -qdfp option is required to process DFP code in headers.
#endif
#endif
#endif
*/

gdb-7.5 ezzel örvendeztet meg:

cc1: warnings being treated as errors
bfd.c: In function '_bfd_abort':
bfd.c:1047: error: 'noreturn' function does return

"Némely emberi agy egészen másképp működik, mint ahogy azt elvárnánk" (Váncsa István)

Minek tették a CFLAGS-ba a -Werror-t, ha nem gondolták komolyan?!

Na jó, hát lehet, hogy nem kizárólag a gdb-team a hibás, inkább csak annyi, hogy fel sem merült bennük, hogy esetleg nem csak linux+gcc a világ... szóval ha /usr/local/include/unistd.h -ba beteszünk egy ilyet:

void _exit(int) __attribute__ ((noreturn));

akkor remélhetőleg jó lesz

Nem erted, az a lenyeg, hogy konkret karakterpoziciot kell megjelolni. Ha a nulladik poziciot jeloli meg - az nem az, ha az elsot - az sem. Az ures sztring az pontosan minden feledik pozicioban van jelen - viszont nem adhat vissza tortszamot.

Nem adhat vissza ervenyes poziciot, mert ilyen nincsen, ha visszaad, nem ellenorizheto vissza.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Elmentem kicsinyég, remélve, hogy a gdb addig lefordul. Le is fordult. Majdnem jól:


$ dump -H $(which gdb) | grep src
3 /usr/local/src/gdb-7.5/bfd/.libs libbfd-2.22.52.20120718.so
8 /usr/local/src/gdb-7.5/opcodes/.libs libopcodes-2.22.52.20120718.so

Na pontosan ennek nem lenne szabad lennie benne, mert a gdb-nek akkor is mennie kellene, ha a forrást törlöm a /usr/local/src-ből.

PS: Megnéztem egy másik gépen a gdb-7.3.1-et, a hiba ott is fennáll. (Ismét igazolódott a régi mondás, hogy hiba csak ott van, ahová nézünk. Vagy fordítva: ahova nézünk, ott találunk egy hibát.)

Nagyobb kompatibilitás miatt a *.la fájlokban ezentúl két dependency_libs lesz, az egyik a hagyományos libtool-nak, a másik önmagunknak, a különbség a la-nélküli libek tárolásában van:

native_dependency_libs=' /orabin/lib32/libclntsh.so'
dependency_libs=' -L/orabin/lib32 -lclntsh'

Na nem mintha kezdeném megkedvelni a hagyományos libtool-t... nemcsak hogy a major-verziókat nem tárolja (az egész projekt ezzel kezdődött ugyebár), de a relatív path-nevek használata is elég furcsán tud kinézni, pl:

$ ldd .libs/rszig
.libs/rszig needs:
         /home/projects/lib/libubio.so
         /home/projects/lib/libdevel_rt.so
         ./.libs/libird.so
         /home/projects/lib/libboci.so

Azsongya nekem a pkg-config, hogy:

/usr/include/pthread.h:666:19: error: unknown type name 'pthread_spinlock_t'

Ez vajon volt már, vagy új?

Persze, igazából csak átnevezem én is...

És már itt is a következő: openssl-1.0.1c

md4_dgst.c: In function 'md4_block_data_order':
md4_dgst.c:111:2: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration]
md4_dgst.c:111:2: error: expected ')' before ':' token

gengetopt:

g++: internal compiler error: Segmentation fault (program as)

Lehet, hogy ebből egy 'gas' lesz hamarosan?

findutils:

ld: 0711-317 ERROR: Undefined symbol: .alloca

ugyanis az 'alloca' nem externként kellene működjön, hanem 'valahogy speciálisan'
Ez a problémát is a -std=c99 opció okozza valamiképpen...
vagy ha effektíve include-oljuk az alloca.h-t (amolyan kultúrember módjára), akkor sincs baj.

Kérdés magamhoz: linux-ban bele lehet (bele érdemes) tenni egy shared libbe az ő függőségeinek a helyét? Tessék szépen kinyomozni!

Executable esetén ez már megy:
$ readelf -d smsserv

Dynamic section at offset 0x2ef8 contains 26 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libdevel_core.so.0]
0x00000001 (NEEDED) Shared library: [libdevel_rt.so.0]
0x00000001 (NEEDED) Shared library: [libsms.so.0]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/home/projects/sms/src/.libs:/home/projects/lib]

A jáváról van szó, hogy pontosítsam: ugyebár JNI esetén behúz egy libValamiJni.so-t. De persze az a libValamiJni.so csak egy közvetítő, az igazi monkát a libvalami.so végzi. Mármint, ha a dlopen megtalálja a libvalami.so-t. Van ugyan egy -Djava.library.path=
opció, de az csak a libValamiJni.so betöltésében segít, a további betöltésben nem.

Valamiért jobban tetszik nekem a gondolat, hogy legyen benne a path magában az elemben... ezt a 'rendes' libtool is megteszi.

Közben született még egy szépítési igény: kis programocskám a --mode=install során megismétli a linkelést, ami persze még nem bűn, csak éppen nem törli maga után az átmeneti fájlt. Még ez sem lett volna baj, ha nem kellene néha root-ként installálni (/usr/local/bin-be), néha meg mezei userként (/home/projects/sms/bin) -- az előbbi lehetetlenné teszi az utóbbit. (Persze az is igaz, hogy ebben a konkrét esetben ez elhárítható, de temporális fájlt hagyni magunk után mindenképp hiba.)

Ez a hibajelenség:
ld: 0711-931 SEVERE ERROR: Output file: .libs/smssendI
The file is write-protected.
collect2: ld returned 12 exit status

Ez is megvan... lassan, de biztosan közeledünk a béta-tesztelhető állapothoz... Mondjuk gyenge pontja a dolognak, hogy rajtam kívül senki se kíváncsi rá -- persze meg is értem: ki akarna egy teszteletlen termékkel kísérletezni a céges gépen. (Mármint engem kivéve: az egóm mérete és a kísérletezőkedvem messze túllépi a mezei programozótól elvárhatót.)

Nekem, mint uzemeltetonek viszont a hatam borsozik az ilyen megoldasoktol. Linuxon amugy a legtobb "nagy" gyarto siman LD_LIBRARY_PATH-tel adja meg, hogy mi hol van, es csa. Ez legalabb tud dinamikus is lenni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Számos lehetőség van, pl:

1. oda telepítesz, ahová akarsz, de az install a bináris programokat újralinkeli a választott path-nak megfelelően. Pl: Oracle AIX-on

$ dump -H -X64 /orabin/OraHome_4/bin/sqlplus
INDEX PATH BASE MEMBER
0 /orabin/OraHome_4/sqlplus/lib/:/orabin/OraHome_4/lib/:/usr/lib:/lib

2. Ora telepítesz, ahová akarsz, a bináris program helyett script-eket futtatsz, a script készíti elő a környezeti változókat. Pl: firefox linuxon

3. Előre definiált helyre telepítesz, a bináris program és a lib is fix helyre kerül. Pl: rpm/deb csomagból telepítés.

4. Magad fordítasz, libtool-lal. A libtool beállítja a rpath/libipath mezőket a binárisban.