| … | |
… | |
| 346 | |
346 | |
| 347 | These can be found at |
347 | These can be found at |
| 348 | L<http://cvs.schmorp.de/deliantra/Deliantra-Client/util/>, but looking at |
348 | L<http://cvs.schmorp.de/deliantra/Deliantra-Client/util/>, but looking at |
| 349 | them can lead to premature blindless. |
349 | them can lead to premature blindless. |
| 350 | |
350 | |
|
|
351 | =item Shared Libraries |
|
|
352 | |
|
|
353 | It is often desirable to package shared libraries - for example the |
|
|
354 | Deliantra client packages SD>, Berkely DB, Pango and amny other libraries |
|
|
355 | that are unlikely to be available on the target system. |
|
|
356 | |
|
|
357 | This usually requires some fiddling (see below), and additionally some |
|
|
358 | environment variables to be set. |
|
|
359 | |
|
|
360 | For example, on ELF systems you usually want F<LD_LIBRARY_PATH=.> and on |
|
|
361 | OS X, you want F<DYLD_LIBRARY_PATH=.> (these are effectively the default |
|
|
362 | on windows). |
|
|
363 | |
|
|
364 | These can most easily be specified when building the packfile: |
|
|
365 | |
|
|
366 | urlader-util ... LD_LIBRARY_PATH=. ./perl run |
|
|
367 | |
|
|
368 | =item Portability: RPATH |
|
|
369 | |
|
|
370 | Often F<perl> is linked against a shared F<libperl.so> - and might be so |
|
|
371 | using an rpath. Perl extensikns likewise might use an rpath, which means |
|
|
372 | the binary will mostly ignore LD_LIBRARY_PATH, which leads to trouble. |
|
|
373 | |
|
|
374 | There is an utility called F<chrpath>, whose F<-d> option can remove the |
|
|
375 | rpath from binaries, shared library and shared objects. |
|
|
376 | |
|
|
377 | =item Portability: OS X DLL HELL |
|
|
378 | |
|
|
379 | OS X has the most severe form of DLL hell I have seen - if you link |
|
|
380 | against system libraries, which is practically unavoidable, you get |
|
|
381 | libraries of well-known names (e.g. libjpeg) that have nothing to do with |
|
|
382 | what you normally expect libjpeg to be, and there is no way to get your |
|
|
383 | version of libjpeg into your program. |
|
|
384 | |
|
|
385 | Moreover, even if apple ships well-known libraries (e.g. libiconv), they |
|
|
386 | often ship patched versions which have a different ABI or even API then |
|
|
387 | the real releases. |
|
|
388 | |
|
|
389 | The only way aorund this I found was to change all library names |
|
|
390 | in my releases (libjpeg.dylib becomes libdeliantra-jpeg.dylin and |
|
|
391 | so on), by patching the paths in the share dlibraries and shared |
|
|
392 | objects. F<install-name-tool> (with F<-id> and F<-change>) works in many |
|
|
393 | cases, but often paths are embedded indirectly, so you might have to use a |
|
|
394 | I<dirty> string replacement. |
|
|
395 | |
| 351 | =back |
396 | =back |
| 352 | |
397 | |
| 353 | =head1 AUTHOR |
398 | =head1 AUTHOR |
| 354 | |
399 | |
| 355 | Marc Lehmann <schmorp@schmorp.de> |
400 | Marc Lehmann <schmorp@schmorp.de> |
