Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libamsrun.a (des undef sous Solaris) #7801

Closed
vicuna opened this issue Oct 25, 2002 · 3 comments
Closed

libamsrun.a (des undef sous Solaris) #7801

vicuna opened this issue Oct 25, 2002 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Oct 25, 2002

Original bug ID: 1456
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

Je veux exporter vers python via C un ensemble d'utilitaires ecrit
en ocaml (3.06).
Pour cela :

  • je compile (ocamlopt) les source ocamls
  • je genére un .o (-output-obj)
  • je link le tout (/usr/ucb/ld -G ... -lunix -lstr -lasmrun -lcurses -o ...)

Sous Linux, tout ca marche trés bien.
Sous Sun/Solaris2.7, quand je charge la librairie via python j'ai le
message suivant:

ImportError: ld.so.1: python2.1: fatal: relocation error: file
/home/dm2s0006/letrTool/SunOS5/bin/../lib/python1.5/srncmodule.so:
symbol __ashrdi3: referenced symbol not found

Apres avoir regardé de plus prés, __ashrdi3 est "utilisé" implicitement
par la fonction Int64_val dans le fichier ints.c (byterun).

Dans ocamlrun, elle est bien définie

0003cde8 ? CTOR_END
0003cde4 ? CTOR_LIST
0003cdf0 ? DTOR_END
0003cdec ? DTOR_LIST
0003cdf4 ? EH_FRAME_BEGIN
0003cdf4 ? FRAME_END
00029844 T __ashldi3
0002988c T __ashrdi3
0003e370 B __ctype
U __deregister_frame_info
U __div64
00029998 t __do_global_ctors_aux
00016654 t __do_global_dtors_aux

Dans libamsrun.a (ou libcamlrun.a d'ailleurs), elle n'est pas définie

ints.o:
U .div
U .rem
U .umul
U Double_val
000006e4 T Int64_val
U __ashldi3
U __ashrdi3
U __div64
U __dtoll
U __floatdidf
U __lshrdi3
U __mul64
U __rem64

  • Est'il normal qu'elle ne soit pas définie dans libamsrun.a ?
  • Est que j'ai oublié de linker avec quelque chose ? (j'ai cherché
    désespérement une librairie qui pouvait le définir mais je n'ai
    pas trouvé)
  • Est ce que j'ai raté quelque chose ?

Merci d'avance.

Gilles Arnaud.

--

_________________ gilles.arnaud@cea.fr _________________

Gilles ARNAUD * Commissariat a l'Energie Atomique Saclay
DEN/DM2S/SFME/LETR, bat 470 * 91191 GIF SUR YVETTE CEDEX
Fax : +33 1 69 08 85 68 -- Phone : +33 1 69 08 38 86


@vicuna
Copy link
Author

vicuna commented Oct 25, 2002

Comment author: administrator

Date: Fri, 25 Oct 2002 11:18:44 +0200 (MET DST)
From: gilles.arnaud@cea.fr

  • Est que j'ai oublié de linker avec quelque chose ? (J'ai cherché
    désespérement une librairie qui pouvait le définir mais je n'ai
    pas trouvé)
    Je soupçonne que c'est défini dans libgcc.a (c'est comme ça sur mes
    machines Solaris, en tous cas). Il est probable qu'en linkant avec
    gcc plutôt que directement avec /usr/ucb/ld, gcc ajoute les bonnes
    librairies (celles de son propre runtime, en tous cas).

Bruno.

@vicuna
Copy link
Author

vicuna commented Oct 25, 2002

Comment author: administrator

Bruno.Verlyck@inria.fr wrote:

Date: Fri, 25 Oct 2002 11:18:44 +0200 (MET DST)
From: gilles.arnaud@cea.fr

  • Est que j'ai oublié de linker avec quelque chose ? (J'ai cherché
    désespérement une librairie qui pouvait le définir mais je n'ai
    pas trouvé)
    Je soupçonne que c'est défini dans libgcc.a (c'est comme ça sur mes
    machines Solaris, en tous cas). Il est probable qu'en linkant avec
    gcc plutôt que directement avec /usr/ucb/ld, gcc ajoute les bonnes
    librairies (celles de son propre runtime, en tous cas).

Bruno.

effectivement, __ashldi3 est bien dans la libgcc.a
J'ai donc linké avec gcc -shared -nostartfiles ...
ca continue de merder

ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

mais c'est bien un problème de link

Merci de l'info.

Gilles.

--

_________________ gilles.arnaud@cea.fr _________________

Gilles ARNAUD * Commissariat a l'Energie Atomique Saclay
DEN/DM2S/SFME/LETR, bat 470 * 91191 GIF SUR YVETTE CEDEX
Fax : +33 1 69 08 85 68 -- Phone : +33 1 69 08 38 86


@vicuna
Copy link
Author

vicuna commented Oct 21, 2003

Comment author: administrator

Final linking must be done by GCC (or link with libgcc.a)

@vicuna vicuna closed this as completed Oct 21, 2003
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant