| Title: | Alpha Migration Tools - Digital Confidential |
| Notice: | Kits: VEST v1.1A: Note 15.60, mx v1.2-4: Notes 4.23 & 4.24 |
| Moderator: | TALLIS::GORTON |
| Created: | Wed Jun 13 1990 |
| Last Modified: | Mon May 26 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 970 |
| Total number of notes: | 4239 |
I have a gen_alpha_bins script that chews through a directory of SunOS4 binaries and shell scripts, creating a new directory of D.UNIX binaries and (verbatim) shell scripts. (Actually, a tiny script sets LD_BIND_NOW and such before invoking the D.UNIX binary of the similar name.) The script distinguishes files in an executable directory by applying FreePort Express to each input file having magic number '^A^C^A^K'. Now I discover some newer SunOS4 software whose binaries are a mixture of files with magic='^A^C^A^K' and magic='M-^A^C^A^K'. (Sorry, I don't have hex codes handy for those strings of ASCII control or meta-control characters.) I suppose the meta- bit of a string character adds 0x80 to it. It happens that when I apply FPX v1.1 to a "SunOS4 binary" in a certain Xilinx CAD software kit, and the binary has magic='M-^A^C^A^K', FPX v1.1 fails thus: BORG-362> fpx -o fsim.alpha fsim.sparc fpx info: Translating fsim.sparc to make fsim.alpha FreePort Express is a licensed product of Digital Equipment Corporation fpxt version V1.1 built Jul 26 1996 19:15:31 /usr/ucb/ld: Unresolved: __mb_cur_max_spf64 *** Exit 1 Stop. Can you tell me what's different about Sun binaries with magic 'M-^A^C^A^K' as opposed to '^A^C^A^K'? Do you recognize the unresolved reference and know what I can do about it? No shared libs were shipped with these new Sun binaries, so I don't know what libs I'm missing, if any. I have this libc: BORG-363> ls -lt /usr/shlib/libc*fpx* 2678784 Dec 2 16:34 /usr/shlib/libc.so.1.109.fpx.so Thanks --gw
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 960.1 | NETRIX::"[email protected]" | Ke-Wei Ma | Tue Mar 25 1997 16:20 | 21 | |
By default, translated executables are linked with our SunOS compatible library, libc.so.1.109. In this case, _mb_cur_max is defined in Sun's libc but not documented, so it was NOT included in our implementation (since we have no idea what it does). Because the references in the main image will go unresolved, this is why you get the link error. There are several things one can do to get around this. The least involved and only functionally correct thing to do is to translate the SunOS libc from your Sun box. Example, fpx foo -o bar libc.so.1.9 This will cause program foo to be translated and linked with a translated Sun libc. If a translated libc.so.1.9 is not found, fpx will translate it for you, assuming the original is around. Ke-Wei I [Posted by WWW Notes gateway] | |||||