PLD-doc: AMD64.txt (NEW)

[Jakub Bogusz]

On Fri, Jan 09, 2004 at 10:35:57AM +0100, jajcus wrote:
>     Z punktu widzenia przenoszenia oprogramowania istotne są następujące 
>     różnice:
> 
>       1. sizeof(long)=8, na x86: sizeof(long)=4. Co za tym idzie,
>          także size_t, time_t i parę innych typów jest 64-bitowych.
> 
>       2. sizeof(void *)=8, na x86: sizeof(void *)=4. To samo dla wszystkich
>          innych wskaźników.
> 
>       3. obiekty konsolidowane do bibliotek dzielonych _muszą_ być kompilowane
>          z opcją -fPIC. Możliwe że to tymczasowe ograniczenie linkera, ale
> 	 ta opcja i tak powinna być przy tworzeniu bibliotek dzielonych 
> 	 zawsze używana.
> 
>       4. aby w systemie z oprogramowaniem 64-bitowym można było korzystać
>          także z pakietów 32-bitowych biblioteki wrzucane są nie do /usr/lib,
> 	 ale do /usr/lib64. Patrz rozdział "/usr/lib64 czy /usr/lib?".

1-3 dotyczy także alphy.
3 przejściowo w niektórych przypadkach ppc (SEGV w binutils)
1,2 w przyszłości sparc64/ppc64/ia64
4 w przyszłości sparc64/ppc64

Może ten dokument napisać ogólniej, żeby nie kopiować dużych części?

>    4. Pliki dla biblioteki dzielonej kompilowane bez -fPIC.
>       
>       Objawia się to komunikatem błędu podczas konsolidacji:
>       "relocation R_X86_64_32S can not be used when making a
>       +shared object; recompile with -fPIC".

Na alphie komunikat jest bardziej enigmatyczny... i warto go gdzieś
opisać, bo mało kto wie, o co chodzi.
Brzmi "gp-relative relocation against dynamic symbol <nazwa>".

>       W takim przypadku należy się upewnić, że wszystkie pliki
>       które są konsolidowane do biblioteki dzielonej zostały skompilowane
>       z opcją -fPIC. Najprostszym rozwiązaniem (ale często nie najlepszym)
>       jest dodanie -fPIC do CFLAGS przekazywanego do %configure.

Porządniej - zwykle używać noinst_LTLIBRARIES zamiast noinst_LIBRARIES;
unikać -static czy -prefer-non-pic tam, gdzie budowane są biblioteki lub
moduły dzielone.

>     Obecnie chyba prawidłowo zrobiony jest Tcl i Ruby. Tcl nauczony jest
>     szukać swoich pakietów zarówno w /usr/lib64 i w /usr/lib. Trzeba tylko
>     zadbać żeby pakiety te, zależnie od tego czy są binarne, czy nie, trafiały
>     do odpowiedniego katalogu. Ruby trzyma swoją standardową bibliotekę
>     w /usr/lib64/ruby/, a dodatkowe moduły wrzucane są do /usr/lib/ruby/.
>     Problemu z /usr/lib/ruby/ nie ma, bo binarne moduły zbudowane dla
>     architektur 32-bitowych trafiają do innego podkatalogu niż te dla AMD64.
>     Perlowi i Pythonowi trzeba się jeszcze przyjrzeć.

Aktualnie dzięki Radkowi Perl wrzuca moduły noarch do /usr/share/perl5,
a zależne od architektury do /usr/lib/perl5 - jeśli w tym drugim
przypadku zamiast lib pochodzi z %{_lib}, to jest OK.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/