Bonjour,

J'essaie actuellement de migrer une application en cobol tournant sur SCO UNIX Openserver release 5 sur une distrib FreeBSD.
J'ai choisie cette distribution car c'est a priori celle qui permet la plus grande interoperabilité au niveau des binaires du runtime cobol et ne disposant
pas des sources de l'application je ne peux absolument pas recompiler les programmes cobol.

A priori la dernière version de freeBSD (7.0) permet d'executer des binaires de SCO.

J'ai essayé plusieurs fichiers binaires issues de SCO mais aucun ne fonctionne.

Voici un recapitulatif de ce que j'ai déjà fait avec comme exemple un binaire SCO ls.

# readelf -a ls
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8049d70
Start of program headers: 52 (bytes into file)
Start of section headers: 42576 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 18
Section header string table index: 16



# ./ls
ELF binary type "0" not known.
./ls: Exec format error. Binary file not executable.
# brandelf -t FreeBSD ls
# ./ls
ELF interpreter /usr/lib/libc.so.1 not found
Abort

Ici a priori il y a un problème avec les librairies de gcc
J'ai donc essayé avec le libc.so.1 issu de SCO

Je copie la totalité des librairies sur la FreeBSD
/opt/K/SCO/Unix/5.0.4Eb/usr/lib/

Je crée un lien

#ln -s /usr/lib/libc.so.1 /opt/K/SCO/Unix/5.0.4Eb/usr/lib/


Et quand je fais le ls

# ./ls
Bad system call (core dumped)
# ktrace ./ls
Bad system call (core dumped)
# kdump
1203 ktrace RET ktrace 0
1203 ktrace CALL execve(0xbfbfeb8b,0xbfbfea4c,0xbfbfea54)
1203 ktrace NAMI "./ls"
1203 ktrace NAMI "/usr/lib/libc.so.1"
1203 ls RET execve 0
1203 ls CALL [9512]
1203 ls RET [9512] -1 errno 78 Function not implemented
1203 ls PSIG SIGSYS SIG_DFL
1203 ls NAMI "ls.core"

Ensuite on m'a conseiller d'essayer avec la libc de freeBSD puis mettre les compat 6x,5x,4x...

L'erreur n'est plus la même :
# ktrace ./ls
Segmentation fault (core dumped)
# kdump
1237 ktrace RET ktrace 0
1237 ktrace CALL execve(0xbfbfeb8b,0xbfbfea4c,0xbfbfea54)
1237 ktrace NAMI "./ls"
1237 ktrace NAMI "/usr/lib/libc.so.1"
1237 ls RET execve 0
1237 ls PSIG SIGSEGV SIG_DFL
1237 ls NAMI "ls.core"

Maintenant, je ne sais plus quoi faire j'ai vraiment l'impression que l'emulation SCO ne fonctionne pas sous FreeBSD 7.0.

Peut-être ibsc2 est-il mal installé ??
Pourtant j'ai bien ibcs2_enable="YES" dans mon rc.conf

Peut-être je devrais tester avec une distribution plus ancienne ?

Merci beaucoup de votre aide

Bonjour,

Tu as été vite pour poster ici ;)

Désole, je ne pouvais que te donner le lien, ta question dépasse de loin mes compétences :(

Pour ceux qui n'ont pa suivi, ylianstef a posté sur QOS et je l'ai envoyé ici.

Bjr,

Quote:

A priori la dernière version de freeBSD (7.0) permet d'executer des binaires de SCO.

En ayant  ibcs2.ko  dans le kernel (avec kldload par example), qu'est ce qui dit ?.
Il y a aussi un fichier hello.uu situé dans un répertoire /usr/share/examples/ibcs2 qui doit bien servir à quelque chose  :( .
Peut etre faut il aussi recompiler un kernel avec "options    IBCS2" , pour obtenir un rep /compat quelquechose, pour que les binaires apportés puissent y travailler ?.
Ma modeste contribution :) .

Merci pour la contribution  ;)

D'après ce que j'ai lu le kernel est compilé avec l'option ibcs2 et tu l'active via le rc.conf : ibcs2_enable="YES"

Donc a priori ca c'est ok !

Mais je me demande pourquoi lorsque je fais un brandelf -lv ; ibcs2 n'apparait pas dans la liste ?!
Car si on prend une emulation linux en comparaison, on fait bien :

brandelf -t linux nom_fichier
./nom_fichier

Or la je fais brandelf -t FreeBSD nom_fichier
./nom_fichier

Je comprend pas comment il arrive à comprendre dans ce cas que c'est un executable SCO a émuler et non un executable FreeBSD classique ???

En ce qui concerne le hello.uu je vais creuser un peu .. merci pour la piste

Merci encore

Pour le fichier hello.uu:

Code (]plouf% uudecode hello.uu
uudecode: hello.uu: hello_world[/code):

:) Je pense aussi (si quelqu'un peut confirmer)que le support s'arrete aux vers.3 des systèmes V, et donc que openserver n'est plus suivi, au moins depuis les versions branches 4, et puis nous, on est resté BSD. [code]plouf# brandelf -lv hello.uu known ELF types are: FreeBSD(9) Linux(3) Solaris(6) SVR4(0) brandelf: file 'hello.uu' is not ELF format

Pour ne pas se prendre la tète, il vaudrait peut etre plutot mieux voir du coté deNetBSD.

Merci Dumpy.

En fait il y a 2 types d'executables les COFF et les ELF .
Le fichier hello.uu est un COFF et il fonctionne chez moi.

Mes fichiers SCO Openserver sont des ELF 32, mais je ne sais pas quelle version SVR3,4 ou 5 ?

Il est donc possible effectivement que la version de mes fichiers ne soit plus soutenue par freeBSD, mais c'est à confirmer, et je prefere en être sur avant de changer de distrib.

Du côté linux j'ai trouvé ca : http://linux-abi.sourceforge.net/, c'est seulement pour les architectures i386 mais c'est peut-être valable ?!

J'ai aussi trouvé ce projet, qui peut-être est une solution à mon problème : http://wiki.freebsd.org/LibElf

Bref en attendant je continue mes recherches ...

Merci encore

ylianstef wrote on 17. Apr 2008 at 15:19:

Bonjour, J'essaie actuellement de migrer une application en cobol tournant sur SCO UNIX Openserver release 5 sur une distrib FreeBSD. J'ai choisie cette distribution car c'est a priori celle qui permet la plus grande interoperabilité au niveau des binaires du runtime cobol et ne disposant pas des sources de l'application je ne peux absolument pas recompiler les programmes cobol. A priori la dernière version de freeBSD (7.0) permet d'executer des binaires de SCO. J'ai essayé plusieurs fichiers binaires issues de SCO mais aucun ne fonctionne. Voici un recapitulatif de ce que j'ai déjà fait avec comme exemple un binaire SCO ls. # readelf -a ls ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8049d70 Start of program headers: 52 (bytes into file) Start of section headers: 42576 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 18 Section header string table index: 16 # ./ls ELF binary type "0" not known. ./ls: Exec format error. Binary file not executable. # brandelf -t FreeBSD ls # ./ls ELF interpreter /usr/lib/libc.so.1 not found Abort Ici a priori il y a un problème avec les librairies de gcc J'ai donc essayé avec le libc.so.1 issu de SCO

Mais là tu dis que le type de l'elf est FreeBSD, c'est faux c'est un exécutable d'un autre système.


Quote:

Et quand je fais le ls # ./ls Bad system call (core dumped) # ktrace ./ls Bad system call (core dumped) # kdump 1203 ktrace RET ktrace 0 1203 ktrace CALL execve(0xbfbfeb8b,0xbfbfea4c,0xbfbfea54) 1203 ktrace NAMI "./ls" 1203 ktrace NAMI "/usr/lib/libc.so.1" 1203 ls RET execve 0 1203 ls CALL [9512] 1203 ls RET [9512] -1 errno 78 Function not implemented 1203 ls PSIG SIGSYS SIG_DFL 1203 ls NAMI "ls.core"

Tu ne peux pas utiliser Kdump ou truss. Kdump utilise le numéro de l'appel système qui diffère suivant l'émulation. Par défaut il mappe les appels systèmes comme si c'était du FreeBSD. Pour l'émulation linux par exemple il faut utiliser le linuxkdump qu'on trouve dans les ports (pas sûr du nom).

J'en sais pas plus pour ton problème...

Merci pour ta réponse,

Tu as raison, normalement je n'ai pas à faire de brandelf -t freeBSD !!
Mais après avoir tout essayé, je crois que rien ne fonctionne !!

En ce qui concerne les appels systèmes tu as vu juste aussi, par contre rien dans les ports concernant un ktrace/kdump linux ou sco.

Ce qui est sur ce que la compatibilité ibcs2 n'est plus maintenue et qu'un jour ou l'autre elle va disparaitre donc pour faire une migration valable il faut que je recompile mon application !

D'après mes lectures, freebsd dans sa version < 5 gére surement beaucoup mieux l'ibcs2 !
Mais cela ne m'interresse pas de migrer vers ces versions.

En tout cas merci pour le coup de main

A bientot