Search Results

Search found 167 results on 7 pages for 'elf'.

Page 1/7 | 1 2 3 4 5 6 7  | Next Page >

  • FreeBSD 8.1 64bit logrotate - ELF interpreter /libexec/ld-elf-so.1 not found

    - by Richard Knop
    I am trying to get logrotate running on a FreeBSD 8.1 virtual machine. I installed the logrotate with pkg_add, I have created the logrotate.config file and also run: mkdir /var/lib/ touch /var/lib/logrotate.status Now when I do: /usr/local/sbin/logrotate -d /usr/local/etc/logrotate.conf I get this error: ELF interpreter /libexec/ld-elf-so.1 not found Abort The file ld-elf-so.1 exists: locate ld-elf.so.1 /libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1 /usr/share/man/man1/ld-elf.so.1.1.gz

    Read the article

  • Error Installing MS office in ubuntu 13.04

    - by Birendra
    While I am installing ms office 10 or 13 using wine it says the following: Unhandled exception: 0xc06d007e in 32-bit code (0x7b83ae0b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b83ae0b ESP:0a6cd3f8 EBP:0a6cd45c EFLAGS:00000287( - -- I S - -P-C) EAX:7b826449 EBX:7b8b0000 ECX:0a6cd480 EDX:0a6cd41c ESI:00dd2428 EDI:00000000 Stack dump: 0x0a6cd3f8: 0a6cd4d0 00000004 000a0009 c06d007e 0x0a6cd408: 00000000 00000000 7b83ae0b 00000001 0x0a6cd418: 0a6cd480 7b8589db 7ffd0c00 00000000 0x0a6cd428: 00000000 00000000 00000000 00000000 0x0a6cd438: 00000000 7ffd0c00 00000000 7b8b0000 0x0a6cd448: 0a6cd468 7b858b2e 00dd24c0 00000000 Backtrace: =>0 0x7b83ae0b in kernel32 (+0x2ae0b) (0x0a6cd45c) 1 0x00dc93bb in msi7bec.tmp (+0x493ba) (0x0a6cd4c4) 2 0x00dc78d8 in msi7bec.tmp (+0x478d7) (0x0a6cd704) 3 0x00dc28cd in msi7bec.tmp (+0x428cc) (0x0a6cd940) 4 0x00d9caf8 in msi7bec.tmp (+0x1caf7) (0x0a6ce83c) 5 0x7def9393 CUSTOMPROC_wrapper+0xa() in msi (0x0a6ce848) 6 0x7def9671 CUSTOMPROC_wrapper+0x2e8() in msi (0x0a6ce9a8) 7 0x7def994f CUSTOMPROC_wrapper+0x5c6() in msi (0x0a6ce9f8) 8 0x7bc7f84c call_thread_func_wrapper+0xb() in ntdll (0x0a6cea08) 9 0x7bc7f89b call_thread_func+0x44() in ntdll (0x0a6ceae8) 10 0x7bc7f82a in ntdll (+0x6f829) (0x0a6ceb08) 11 0x7bc871f3 in ntdll (+0x771f2) (0x0a6cf368) 12 0xf75c5d78 start_thread+0xd7() in libpthread.so.0 (0x0a6cf468) 13 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 14 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 15 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 16 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 17 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 18 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 19 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 20 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 21 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 22 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 23 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 24 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 25 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 26 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 27 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 28 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 29 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 30 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 31 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 32 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 33 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 34 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 35 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 36 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 37 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 38 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 39 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 40 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 41 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 42 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 43 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 44 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 45 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 46 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 47 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 48 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 49 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 50 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 51 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 52 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 53 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 54 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 55 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 56 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 57 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 58 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 59 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 60 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 61 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 62 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 63 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 64 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 65 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 66 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 67 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 68 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 69 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 70 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 71 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 72 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 73 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 74 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 75 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 76 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 77 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 78 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 79 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 80 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 81 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 82 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 83 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 84 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 85 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 86 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 87 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 88 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 89 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 90 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 91 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 92 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 93 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 94 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 95 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 96 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 97 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 98 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 99 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 100 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 101 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 102 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 103 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 104 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 105 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 106 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 107 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 108 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 109 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 110 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 111 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 112 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 113 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 114 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 115 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 116 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 117 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 118 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 119 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 120 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 121 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 122 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 123 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 124 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 125 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 126 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 127 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 128 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 129 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 130 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 131 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 132 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 133 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 134 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 135 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 136 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 137 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 138 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 139 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 140 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 141 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 142 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 143 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 144 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 145 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 146 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 147 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 148 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 149 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 150 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 151 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 152 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 153 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 154 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 155 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 156 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 157 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 158 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 159 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 160 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 161 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 162 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 163 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 164 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 165 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 166 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 167 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 168 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 169 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 170 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 171 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 172 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 173 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 174 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 175 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 176 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 177 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 178 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 179 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 180 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 181 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 182 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 183 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 184 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 185 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 186 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 187 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 188 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 189 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 190 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 191 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 192 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 193 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 194 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 195 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 196 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 197 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 198 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 199 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 200 0xf74fc3de __clone+0x5d() in libc.so.6 (0x00000000) 0x7b83ae0b: subl $4,%esp Modules: Module Address Debug info Name (149 modules) PE 840000- 86f000 Deferred osetupui PE ba0000- ba7000 Deferred msi7c0d.tmp PE d40000- d51000 Deferred msi7bb6.tmp PE d80000- ddd000 Export msi7bec.tmp PE de0000- df8000 Deferred msi83ed.tmp PE e00000- e0a000 Deferred msi83f8.tmp PE f40000- 1072000 Deferred pidgenx PE 1440000- 145a000 Deferred msi958a.tmp PE 9e80000- 9edb000 Deferred msi889c.tmp PE 9ee0000- 9f0a000 Deferred msi9130.tmp PE 10000000-10593000 Deferred osetup PE 2e000000-2e119000 Deferred setup PE 41110000-41155000 Deferred msi7bd6.tmp PE 504a0000-504c7000 Deferred msi9112.tmp PE 504d0000-504f0000 Deferred msi8b04.tmp ELF 7b800000-7ba44000 Dwarf kernel32<elf> \-PE 7b810000-7ba44000 \ kernel32 ELF 7bab6000-7bb00000 Deferred libdbus-1.so.3 ELF 7bc00000-7bce4000 Dwarf ntdll<elf> \-PE 7bc10000-7bce4000 \ ntdll ELF 7be0f000-7be32000 Deferred localspl<elf> \-PE 7be10000-7be32000 \ localspl ELF 7be32000-7bf00000 Deferred libkrb5.so.3 ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7bf09000-7bf25000 Deferred spoolss<elf> \-PE 7bf10000-7bf25000 \ spoolss ELF 7bf25000-7bf3c000 Deferred libresolv.so.2 ELF 7bf3c000-7bf64000 Deferred libk5crypto.so.3 ELF 7bf64000-7bfa1000 Deferred libgssapi_krb5.so.2 ELF 7bfa1000-7c000000 Deferred libcups.so.2 ELF 7c208000-7c2aa000 Deferred msvcrt<elf> \-PE 7c220000-7c2aa000 \ msvcrt ELF 7c2aa000-7c400000 Deferred libxml2.so.2 ELF 7c40c000-7c415000 Deferred librt.so.1 ELF 7c415000-7c427000 Deferred libavahi-client.so.3 ELF 7c427000-7c468000 Deferred winspool<elf> \-PE 7c430000-7c468000 \ winspool ELF 7c468000-7c485000 Deferred libgcc_s.so.1 ELF 7c485000-7c4c2000 Deferred libxslt.so.1 ELF 7c4c2000-7c4e9000 Deferred liblzma.so.5 ELF 7c4e9000-7c59e000 Deferred msxml3<elf> \-PE 7c4f0000-7c59e000 \ msxml3 ELF 7c59e000-7c5cd000 Deferred msxml6<elf> \-PE 7c5a0000-7c5cd000 \ msxml6 ELF 7d0e1000-7d0ea000 Deferred libkrb5support.so.0 ELF 7d0ea000-7d0f8000 Deferred libavahi-common.so.3 ELF 7d5b5000-7d5b9000 Deferred libkeyutils.so.1 ELF 7d5b9000-7d5be000 Deferred libcom_err.so.2 ELF 7d5d6000-7d63e000 Deferred riched20<elf> \-PE 7d5e0000-7d63e000 \ riched20 ELF 7d63e000-7d672000 Deferred hhctrl<elf> \-PE 7d640000-7d672000 \ hhctrl ELF 7d672000-7d696000 Deferred hlink<elf> \-PE 7d680000-7d696000 \ hlink ELF 7d696000-7d6b6000 Deferred oleacc<elf> \-PE 7d6a0000-7d6b6000 \ oleacc ELF 7d6b6000-7d6fa000 Deferred rsaenh<elf> \-PE 7d6c0000-7d6fa000 \ rsaenh ELF 7d6fa000-7d715000 Deferred imagehlp<elf> \-PE 7d700000-7d715000 \ imagehlp ELF 7d72d000-7d764000 Deferred uxtheme<elf> \-PE 7d730000-7d764000 \ uxtheme ELF 7d764000-7d76b000 Deferred libxfixes.so.3 ELF 7d76b000-7d776000 Deferred libxcursor.so.1 ELF 7d7f6000-7d81e000 Deferred libexpat.so.1 ELF 7d81e000-7d857000 Deferred libfontconfig.so.1 ELF 7d857000-7d867000 Deferred libxi.so.6 ELF 7d867000-7d872000 Deferred libxrandr.so.2 ELF 7d872000-7d87c000 Deferred libxrender.so.1 ELF 7d87c000-7d882000 Deferred libxxf86vm.so.1 ELF 7d882000-7d8a6000 Deferred imm32<elf> \-PE 7d890000-7d8a6000 \ imm32 ELF 7d8a6000-7d8ad000 Deferred libxdmcp.so.6 ELF 7d8ad000-7d8cf000 Deferred libxcb.so.1 ELF 7d8cf000-7d8d5000 Deferred libuuid.so.1 ELF 7d8d5000-7d8ef000 Deferred libice.so.6 ELF 7d8ef000-7da26000 Deferred libx11.so.6 ELF 7da26000-7da38000 Deferred libxext.so.6 ELF 7da38000-7da41000 Deferred libsm.so.6 ELF 7da41000-7daf2000 Deferred winex11<elf> \-PE 7da50000-7daf2000 \ winex11 ELF 7daf2000-7db8d000 Deferred libfreetype.so.6 ELF 7dba5000-7dbb9000 Deferred libp11-kit.so.0 ELF 7dbb9000-7dbcb000 Deferred libtasn1.so.3 ELF 7dbcb000-7dc4f000 Deferred libgcrypt.so.11 ELF 7dc4f000-7dd14000 Deferred libgnutls.so.26 ELF 7dd14000-7dd38000 Deferred cabinet<elf> \-PE 7dd20000-7dd38000 \ cabinet ELF 7dd38000-7dd61000 Deferred mpr<elf> \-PE 7dd40000-7dd61000 \ mpr ELF 7dd61000-7dd7a000 Deferred libz.so.1 ELF 7dd7b000-7dd7f000 Deferred libxcomposite.so.1 ELF 7dd7f000-7dd92000 Deferred gnome-keyring-pkcs11.so ELF 7dd92000-7de0c000 Deferred wininet<elf> \-PE 7dda0000-7de0c000 \ wininet ELF 7de0c000-7deb9000 Deferred urlmon<elf> \-PE 7de20000-7deb9000 \ urlmon ELF 7deb9000-7dfdb000 Dwarf msi<elf> \-PE 7dec0000-7dfdb000 \ msi ELF 7dfdb000-7e04b000 Deferred dbghelp<elf> \-PE 7dfe0000-7e04b000 \ dbghelp ELF 7e04b000-7e121000 Deferred crypt32<elf> \-PE 7e050000-7e121000 \ crypt32 ELF 7e121000-7e15b000 Deferred wintrust<elf> \-PE 7e130000-7e15b000 \ wintrust ELF 7e15b000-7e27a000 Deferred comctl32<elf> \-PE 7e160000-7e27a000 \ comctl32 ELF 7e27a000-7e2f0000 Deferred shlwapi<elf> \-PE 7e290000-7e2f0000 \ shlwapi ELF 7e2f0000-7e52e000 Deferred shell32<elf> \-PE 7e300000-7e52e000 \ shell32 ELF 7e52e000-7e673000 Deferred oleaut32<elf> \-PE 7e540000-7e673000 \ oleaut32 ELF 7e673000-7e754000 Deferred gdi32<elf> \-PE 7e680000-7e754000 \ gdi32 ELF 7e754000-7e8c4000 Deferred user32<elf> \-PE 7e770000-7e8c4000 \ user32 ELF 7e8c4000-7ea26000 Deferred ole32<elf> \-PE 7e8e0000-7ea26000 \ ole32 ELF 7ea26000-7eab0000 Deferred rpcrt4<elf> \-PE 7ea30000-7eab0000 \ rpcrt4 ELF 7eab0000-7eae4000 Deferred ws2_32<elf> \-PE 7eac0000-7eae4000 \ ws2_32 ELF 7eae4000-7eb56000 Deferred advapi32<elf> \-PE 7eaf0000-7eb56000 \ advapi32 ELF 7eb56000-7eb7b000 Deferred iphlpapi<elf> \-PE 7eb60000-7eb7b000 \ iphlpapi ELF 7eb7b000-7ebaa000 Deferred netapi32<elf> \-PE 7eb80000-7ebaa000 \ netapi32 ELF 7ebaa000-7ebdf000 Deferred secur32<elf> \-PE 7ebb0000-7ebdf000 \ secur32 ELF 7ebdf000-7ebfa000 Deferred version<elf> \-PE 7ebe0000-7ebfa000 \ version ELF 7ebfa000-7ec07000 Deferred libnss_files.so.2 ELF 7ec07000-7ec13000 Deferred libnss_nis.so.2 ELF 7ec13000-7ec2c000 Deferred libnsl.so.1 ELF 7ec2c000-7ec35000 Deferred libnss_compat.so.2 ELF 7efa5000-7efe8000 Deferred libm.so.6 ELF 7efe8000-7efec000 Deferred libxinerama.so.1 ELF 7efec000-7f000000 Deferred psapi<elf> \-PE 7eff0000-7f000000 \ psapi ELF f7401000-f7405000 Deferred libxau.so.6 ELF f7406000-f740b000 Deferred libdl.so.2 ELF f740b000-f75be000 Dwarf libc.so.6 ELF f75bf000-f75da000 Dwarf libpthread.so.0 ELF f75da000-f75df000 Deferred libgpg-error.so.0 ELF f75f2000-f7736000 Dwarf libwine.so.1 ELF f7738000-f775a000 Deferred ld-linux.so.2 ELF f775a000-f775b000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 0000000e services.exe 0000005b 0 0000005c 0 00000059 0 0000002e 0 0000001f 0 00000015 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001d 0 0000001a 0 00000014 0 00000013 0 0000001b plugplay.exe 00000021 0 0000001e 0 0000001c 0 00000022 explorer.exe 00000023 0 0000002a (D) C:\users\birendra\Desktop\OFFICE 2010\setup.exe 0000005d 0 <== 0000002f 0 0000002b 0 00000042 OSE.EXE 00000045 0 00000047 0 0000002d 0 00000036 0 00000040 0 00000017 0 00000018 0 00000034 0 System information: Wine build: wine-1.4.1 Platform: i386 (WOW64) Host system: Linux Host version: 3.8.0-19-generic Anybody give me suggestion how to fix the problem to install it.

    Read the article

  • LIMBO fails on startup with Internal errors - invalid parameters received

    - by user61262
    I installed LIMBO from the Humble Bundle V and as far as I am aware, this has wine packaged with it (I also installed the latest from the repo's in case is was because of that). However the game doesn't even start and fails with the message: Wine Program Error Internal errors - invalid parameters received. Is there a way to log the error or does anyone know why this happens? This question was asked previously but it seems to have disappeared. My Graphics cards is a Geforece GT 250 Cheers ice. [edit: Wine outputs the following error: wine /opt/limbo/support/limbo/drive_c/Program\ Files/limbo/limbo.exe fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 53 (SPI_SETTOGGLEKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 51 (SPI_SETFILTERKEYS) fixme:win:EnumDisplayDevicesW ((null),0,0x32f580,0x00000000), stub! err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1920x1080x32 @60! (XRandR) err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? wine: Unhandled page fault on read access to 0x00000000 at address 0x48213e (thread 0009), starting debugger... The debugger has the following output: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x0048213e). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0048213e ESP:0032f9f4 EBP:0037cdd0 EFLAGS:00010202( R- -- I - - - ) EAX:00000000 EBX:00000000 ECX:00000000 EDX:0037cf4c ESI:0037cda8 EDI:0037cdcc Stack dump: 0x0032f9f4: 0037cda8 0034c708 7bc35120 00000000 0x0032fa04: 0037cda8 0032fa38 0079fc58 00000000 0x0032fa14: 0048b7d4 00000001 0037cdcc 00000001 0x0032fa24: 00000780 00000438 0034c620 00000000 0x0032fa34: 0034c708 0032fa78 007a04e2 00000002 0x0032fa44: 0048c4bc 00000780 00000438 0037cda8 Backtrace: =>0 0x0048213e in limbo (+0x8213e) (0x0037cdd0) 0x0048213e: movl 0x0(%eax),%edx Modules: Module Address Debug info Name (103 modules) PE 400000- 926000 Export limbo PE 10000000-101ff000 Deferred d3dx9_43 ELF 79bb3000-7b800000 Deferred libnvidia-glcore.so.295.53 ELF 7b800000-7ba15000 Deferred kernel32<elf> \-PE 7b810000-7ba15000 \ kernel32 ELF 7bc00000-7bcc3000 Deferred ntdll<elf> \-PE 7bc10000-7bcc3000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7d7e0000-7d7e4000 Deferred libnvidia-tls.so.295.53 ELF 7d7e4000-7d8bc000 Deferred libgl.so.1 ELF 7d9d0000-7d9d9000 Deferred librt.so.1 ELF 7d9d9000-7d9de000 Deferred libgpg-error.so.0 ELF 7d9de000-7d9f6000 Deferred libresolv.so.2 ELF 7d9f6000-7d9fa000 Deferred libkeyutils.so.1 ELF 7d9fa000-7da43000 Deferred libdbus-1.so.3 ELF 7da43000-7da55000 Deferred libp11-kit.so.0 ELF 7da55000-7dada000 Deferred libgcrypt.so.11 ELF 7dada000-7daec000 Deferred libtasn1.so.3 ELF 7daec000-7daf5000 Deferred libkrb5support.so.0 ELF 7daf5000-7dafa000 Deferred libcom_err.so.2 ELF 7dafa000-7db22000 Deferred libk5crypto.so.3 ELF 7db22000-7dbf1000 Deferred libkrb5.so.3 ELF 7dbf1000-7dc03000 Deferred libavahi-client.so.3 ELF 7dc03000-7dc11000 Deferred libavahi-common.so.3 ELF 7dc11000-7dcd5000 Deferred libgnutls.so.26 ELF 7dcd5000-7dd13000 Deferred libgssapi_krb5.so.2 ELF 7dd13000-7dd66000 Deferred libcups.so.2 ELF 7dd94000-7ddc8000 Deferred uxtheme<elf> \-PE 7dda0000-7ddc8000 \ uxtheme ELF 7ddc8000-7ddd3000 Deferred libxcursor.so.1 ELF 7ddd4000-7dde7000 Deferred gnome-keyring-pkcs11.so ELF 7de47000-7de4d000 Deferred libxfixes.so.3 ELF 7deac000-7ded6000 Deferred libexpat.so.1 ELF 7ded6000-7df0a000 Deferred libfontconfig.so.1 ELF 7df0a000-7df1a000 Deferred libxi.so.6 ELF 7df1a000-7df1e000 Deferred libxcomposite.so.1 ELF 7df1e000-7df27000 Deferred libxrandr.so.2 ELF 7df27000-7df31000 Deferred libxrender.so.1 ELF 7df31000-7df37000 Deferred libxxf86vm.so.1 ELF 7df37000-7df3b000 Deferred libxinerama.so.1 ELF 7df3b000-7df5d000 Deferred imm32<elf> \-PE 7df40000-7df5d000 \ imm32 ELF 7df5d000-7df64000 Deferred libxdmcp.so.6 ELF 7df64000-7df85000 Deferred libxcb.so.1 ELF 7df85000-7df9f000 Deferred libice.so.6 ELF 7df9f000-7e0d3000 Deferred libx11.so.6 ELF 7e0d3000-7e0e5000 Deferred libxext.so.6 ELF 7e0e5000-7e178000 Deferred winex11<elf> \-PE 7e0f0000-7e178000 \ winex11 ELF 7e178000-7e18e000 Deferred libz.so.1 ELF 7e18e000-7e228000 Deferred libfreetype.so.6 ELF 7e228000-7e247000 Deferred libtinfo.so.5 ELF 7e247000-7e269000 Deferred libncurses.so.5 ELF 7e27d000-7e292000 Deferred xinput1_3<elf> \-PE 7e280000-7e292000 \ xinput1_3 ELF 7e292000-7e2a6000 Deferred psapi<elf> \-PE 7e2a0000-7e2a6000 \ psapi ELF 7e2a6000-7e304000 Deferred dbghelp<elf> \-PE 7e2b0000-7e304000 \ dbghelp ELF 7e304000-7e391000 Deferred msvcrt<elf> \-PE 7e320000-7e391000 \ msvcrt ELF 7e391000-7e4c5000 Deferred wined3d<elf> \-PE 7e3a0000-7e4c5000 \ wined3d ELF 7e4c5000-7e4fe000 Deferred d3d9<elf> \-PE 7e4d0000-7e4fe000 \ d3d9 ELF 7e4fe000-7e573000 Deferred rpcrt4<elf> \-PE 7e510000-7e573000 \ rpcrt4 ELF 7e573000-7e67b000 Deferred ole32<elf> \-PE 7e590000-7e67b000 \ ole32 ELF 7e67b000-7e697000 Deferred dinput8<elf> \-PE 7e680000-7e697000 \ dinput8 ELF 7e697000-7e6d1000 Deferred winspool<elf> \-PE 7e6a0000-7e6d1000 \ winspool ELF 7e6d1000-7e7c9000 Deferred comctl32<elf> \-PE 7e6e0000-7e7c9000 \ comctl32 ELF 7e7c9000-7e833000 Deferred shlwapi<elf> \-PE 7e7e0000-7e833000 \ shlwapi ELF 7e833000-7ea44000 Deferred shell32<elf> \-PE 7e840000-7ea44000 \ shell32 ELF 7ea44000-7eb23000 Deferred comdlg32<elf> \-PE 7ea50000-7eb23000 \ comdlg32 ELF 7eb23000-7eb3c000 Deferred version<elf> \-PE 7eb30000-7eb3c000 \ version ELF 7eb3c000-7eb9c000 Deferred advapi32<elf> \-PE 7eb50000-7eb9c000 \ advapi32 ELF 7eb9c000-7ec59000 Deferred gdi32<elf> \-PE 7ebb0000-7ec59000 \ gdi32 ELF 7ec59000-7ed99000 Deferred user32<elf> \-PE 7ec70000-7ed99000 \ user32 ELF 7ef99000-7efa6000 Deferred libnss_files.so.2 ELF 7efa6000-7efc0000 Deferred libnsl.so.1 ELF 7efc0000-7efec000 Deferred libm.so.6 ELF 7efee000-7eff4000 Deferred libuuid.so.1 ELF 7eff4000-7f000000 Deferred libnss_nis.so.2 ELF b7411000-b7415000 Deferred libxau.so.6 ELF b7415000-b741e000 Deferred libnss_compat.so.2 ELF b741f000-b7424000 Deferred libdl.so.2 ELF b7424000-b75ca000 Deferred libc.so.6 ELF b75cb000-b75e6000 Deferred libpthread.so.0 ELF b75e9000-b75f2000 Deferred libsm.so.6 ELF b75fa000-b773c000 Dwarf libwine.so.1 ELF b773e000-b7760000 Deferred ld-linux.so.2 ELF b7760000-b7761000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\opt\limbo\support\limbo\drive_c\Program Files\limbo\limbo.exe 00000009 0 <== 0000000e services.exe 00000020 0 0000001f 0 00000019 0 00000018 0 00000017 0 00000015 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001d 0 0000001a 0 00000014 0 00000013 0 0000001b plugplay.exe 00000021 0 0000001e 0 0000001c 0 00000022 explorer.exe 00000023 0 System information: Wine build: wine-1.4 Platform: i386 Host system: Linux Host version: 3.2.0-24-generic-pae

    Read the article

  • Installing Age of Empires II using PlayOnLinux doesn't work?

    - by user70342
    I have tried installing age of empires 2 using PlayOnLinux, the installation appeared to go fine but when I try and open the game it says there is a serious fault. The error report is below, unfortunately this doesn't mean alot to me, I was wondering if you could help, a) By highlighting the problem and b) by suggesting a solution. Many Thanks Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x0040aaad). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0040aaad ESP:0033fd00 EBP:0033fde4 EFLAGS:00010293( R- -- I S -A- -C) EAX:00000001 EBX:bde88d9d ECX:00000067 EDX:00400000 ESI:7b867c00 EDI:00400000 Stack dump: 0x0033fd00:00410fed 00000000 00400000 00000067 0x0033fd10:0041ab90 00130d8a 7b895848 7bc483b1 0x0033fd20:0044c800 00000002 0044bdd0 7bca4e6c 0x0033fd30:7bc3590f 00000800 00000094 00000005 0x0033fd40:00000000 00000893 00000002 76726553 0x0033fd50:20656369 6b636150 00003420 00000800 Backtrace: =0 0x0040aaad in empires2 (+0xaaad) (0x0033fde4) 1 0x0041ace2 in empires2 (+0x1ace1) (0x0033fe70) 2 0x7b85ac0c call_process_entry+0xb() in kernel32 (0x0033fe88) 3 0x7b85e13b in kernel32 (+0x4e13a) (0x0033fec8) 4 0x7bc714f0 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 5 0x7bc7172d call_thread_func+0x7c() in ntdll (0x0033ffa8) 6 0x7bc714ce RtlRaiseException+0x21() in ntdll (0x0033ffc8) 7 0x7bc4c30e in ntdll (+0x3c30d) (0x0033ffe8) 0x0040aaad: pop %ss Modules: Module Address Debug info Name (51 modules) PE 400000- 44b000 Export empires2 PE 10000000-1000c000 Deferred drvmgt ELF 35cae000-35d24000 Deferred rpcrt4 -PE 35cc0000-35d24000 \ rpcrt4 ELF 68000000-68022000 Deferred ld-linux.so.2 ELF 68022000-681c7000 Deferred libc.so.6 ELF 681c7000-681cc000 Deferred libdl.so.2 ELF 681cc000-681f8000 Deferred libm.so.6 ELF 681f8000-68201000 Deferred libnss_compat.so.2 ELF 68201000-6821b000 Deferred libnsl.so.1 ELF 6821b000-68228000 Deferred libnss_files.so.2 ELF 68228000-68366000 Deferred user32 -PE 68240000-68366000 \ user32 ELF 68366000-68421000 Deferred gdi32 -PE 68370000-68421000 \ gdi32 ELF 68421000-68481000 Deferred advapi32 -PE 68430000-68481000 \ advapi32 ELF 68481000-68499000 Deferred version -PE 68490000-68499000 \ version ELF 68499000-68533000 Deferred libfreetype.so.6 ELF 68533000-68549000 Deferred libz.so.1 ELF 68549000-685db000 Deferred winex11 -PE 68550000-685db000 \ winex11 ELF 685db000-685e4000 Deferred libsm.so.6 ELF 685e4000-685fe000 Deferred libice.so.6 ELF 685fe000-68610000 Deferred libxext.so.6 ELF 68610000-68744000 Deferred libx11.so.6 ELF 68744000-6874a000 Deferred libuuid.so.1 ELF 6874a000-68751000 Deferred libxdmcp.so.6 ELF 68751000-68755000 Deferred libxinerama.so.1 ELF 68755000-6875b000 Deferred libxxf86vm.so.1 ELF 6875b000-68765000 Deferred libxrender.so.1 ELF 68765000-6876e000 Deferred libxrandr.so.2 ELF 6876e000-68772000 Deferred libxcomposite.so.1 ELF 68772000-68782000 Deferred libxi.so.6 ELF 68782000-687b6000 Deferred libfontconfig.so.1 ELF 687b6000-687e0000 Deferred libexpat.so.1 ELF 687e0000-687eb000 Deferred libxcursor.so.1 ELF 687eb000-687f1000 Deferred libxfixes.so.3 ELF 6f102000-6f10e000 Deferred libnss_nis.so.2 ELF 7194d000-7196e000 Deferred imm32 -PE 71950000-7196e000 \ imm32 ELF 72c76000-72db7000 Dwarf libwine.so.1 ELF 75d65000-75d86000 Deferred libxcb.so.1 ELF 79223000-79227000 Deferred libxau.so.6 ELF 7b800000-7b8f5000 Dwarf kernel32 -PE 7b810000-7b8f5000 \ kernel32 ELF 7bc00000-7bcc1000 Dwarf ntdll -PE 7bc10000-7bcc1000 \ ntdll ELF 7bf00000-7bf03000 Deferred ELF 7c708000-7c723000 Deferred libpthread.so.0 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\Microsoft Games\Age of Empires II\empires2.exe 00000009 0 <== 0000000e services.exe 00000039 0 00000038 0 0000001f 0 00000019 0 00000018 0 00000017 0 00000015 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001e 0 0000001a 0 00000014 0 00000013 0 0000001b plugplay.exe 00000021 0 0000001d 0 0000001c 0 00000024 explorer.exe 00000025 0 00000035 winedevice.exe 0000003a 0 00000037 0 00000036 0 System information: Wine build: wine-1.4-rc1 Platform: i386 Host system: Linux Host version: 3.2.0-24-generic

    Read the article

  • How can I read kindle book under xfce(ubuntu)? (using chromebook)(wine not working)

    - by yshn
    I'm using chromebook, dual booting xfce(ubuntu) and cr os. The ebook I bought on amazon is not supported on kindle cloud reader. (Under xfce)I downloaded wine and tried installing kindle for pc under wine, and after couples of times of trials, it always said installation error and could not install kindle, and it's been giving me: Unhandled exception: unimplemented function msvcp90.dll.??0?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAE@XZ called in 32-bit code (0x7b839cf2). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b839cf2 ESP:0033fcd4 EBP:0033fd38 EFLAGS:00000287( - -- I S - -P-C) EAX:7b826245 EBX:7b894ff4 ECX:00000008 EDX:0033fcf4 ESI:80000100 EDI:00dca568 Stack dump: 0x0033fcd4: 0033fd58 00000008 00000030 80000100 0x0033fce4: 00000001 00000000 7b839cf2 00000002 0x0033fcf4: 7e24b340 7e24f2ca 0000000d 00110000 0x0033fd04: 7bc47a0d 7e1dbff4 7e1417f0 00dca568 0x0033fd14: 0033fd24 7bc65d0b 00110000 00000000 0x0033fd24: 0033fd44 7e141801 7b839caa 7e1dbff4 000c: sel=0067 base=00000000 limit=00000000 16-bit r-x Backtrace: =0 0x7b839cf2 in kernel32 (+0x29cf2) (0x0033fd38) 1 0x7e24b2a8 in msvcp90 (+0x3b2a7) (0x0033fd68) 2 0x7e216c9d in msvcp90 (+0x6c9c) (0x0033fde8) 3 0x00938fdd in kindle (+0x538fdc) (0x0033fde8) 4 0x0089dc71 in kindle (+0x49dc70) (0x0033fe70) 5 0x7b859cdc call_process_entry+0xb() in kernel32 (0x0033fe88) 6 0x7b85af4f in kernel32 (+0x4af4e) (0x0033fec8) 7 0x7bc71db0 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 8 0x7bc7486d call_thread_func+0x7c() in ntdll (0x0033ffa8) 9 0x7bc71d8e RtlRaiseException+0x21() in ntdll (0x0033ffc8) 10 0x7bc49f4e call_dll_entry_point+0x61d() in ntdll (0x0033ffe8) 0x7b839cf2: subl $4,%esp Modules: Module Address Debug info Name (130 modules) PE 340000- 37d000 Deferred ssleay32 PE 390000- 3ca000 Deferred webcoreviewer PE 3d0000- 3e0000 Deferred pthreadvc2 PE 400000- 1433000 Export kindle PE 1440000- 155c000 Deferred libeay32 PE 1560000- 169f000 Deferred qtscript4 PE 16a0000- 1795000 Deferred libxml2 PE 17a0000- 18c7000 Deferred javascriptcore PE 18d0000- 1974000 Deferred cflite PE 1980000- 2048000 Deferred libwebcore PE 2050000- 208d000 Deferred libjpeg PE 10000000-10a34000 Deferred qtwebkit4 PE 4a800000-4a8eb000 Deferred icuuc46 PE 4a900000-4aa36000 Deferred icuin46 PE 4ad00000-4bb80000 Deferred icudt46 PE 5a4c0000-5a4d4000 Deferred zlib1 PE 61000000-61056000 Deferred qtxml4 PE 62000000-62093000 Deferred qtsql4 PE 64000000-640ef000 Deferred qtnetwork4 PE 65000000-657b8000 Deferred qtgui4 PE 67000000-67228000 Deferred qtcore4 PE 78050000-780b9000 Deferred msvcp100 PE 78aa0000-78b5e000 Deferred msvcr100 ELF 7b800000-7ba15000 Dwarf kernel32 -PE 7b810000-7ba15000 \ kernel32 ELF 7bc00000-7bcc3000 Dwarf ntdll -PE 7bc10000-7bcc3000 \ ntdll ELF 7bf00000-7bf04000 Deferred ELF 7d7f7000-7d800000 Deferred librt.so.1 ELF 7d800000-7d818000 Deferred libresolv.so.2 ELF 7d818000-7d861000 Deferred libdbus-1.so.3 ELF 7d861000-7d873000 Deferred libp11-kit.so.0 ELF 7d873000-7d8f8000 Deferred libgcrypt.so.11 ELF 7d8f8000-7d90a000 Deferred libtasn1.so.3 ELF 7d90a000-7d913000 Deferred libkrb5support.so.0 ELF 7d913000-7d9e2000 Deferred libkrb5.so.3 ELF 7da42000-7da47000 Deferred libgpg-error.so.0 ELF 7da47000-7da6f000 Deferred libk5crypto.so.3 ELF 7da6f000-7da81000 Deferred libavahi-client.so.3 ELF 7da81000-7da8f000 Deferred libavahi-common.so.3 ELF 7da8f000-7db53000 Deferred libgnutls.so.26 ELF 7db53000-7db91000 Deferred libgssapi_krb5.so.2 ELF 7db91000-7dbe4000 Deferred libcups.so.2 ELF 7dc21000-7dc55000 Deferred uxtheme -PE 7dc30000-7dc55000 \ uxtheme ELF 7dc55000-7dc5b000 Deferred libxfixes.so.3 ELF 7dc5b000-7dc66000 Deferred libxcursor.so.1 ELF 7dc6a000-7dc6e000 Deferred libkeyutils.so.1 ELF 7dc6e000-7dc73000 Deferred libcom_err.so.2 ELF 7dca5000-7dccf000 Deferred libexpat.so.1 ELF 7dccf000-7dd03000 Deferred libfontconfig.so.1 ELF 7dd03000-7dd13000 Deferred libxi.so.6 ELF 7dd13000-7dd17000 Deferred libxcomposite.so.1 ELF 7dd17000-7dd20000 Deferred libxrandr.so.2 ELF 7dd20000-7dd2a000 Deferred libxrender.so.1 ELF 7dd2a000-7dd30000 Deferred libxxf86vm.so.1 ELF 7dd30000-7dd34000 Deferred libxinerama.so.1 ELF 7dd34000-7dd3b000 Deferred libxdmcp.so.6 ELF 7dd3b000-7dd5c000 Deferred libxcb.so.1 ELF 7dd5c000-7dd76000 Deferred libice.so.6 ELF 7dd76000-7deaa000 Deferred libx11.so.6 ELF 7deaa000-7debc000 Deferred libxext.so.6 ELF 7debc000-7dec5000 Deferred libsm.so.6 ELF 7ded4000-7df67000 Deferred winex11 -PE 7dee0000-7df67000 \ winex11 ELF 7df67000-7e001000 Deferred libfreetype.so.6 ELF 7e001000-7e023000 Deferred iphlpapi -PE 7e010000-7e023000 \ iphlpapi ELF 7e023000-7e03e000 Deferred wsock32 -PE 7e030000-7e03e000 \ wsock32 ELF 7e03e000-7e071000 Deferred wintrust -PE 7e040000-7e071000 \ wintrust ELF 7e071000-7e129000 Deferred crypt32 -PE 7e080000-7e129000 \ crypt32 ELF 7e129000-7e158000 Deferred msvcr90 -PE 7e130000-7e158000 \ msvcr90 ELF 7e158000-7e1e5000 Deferred msvcrt -PE 7e170000-7e1e5000 \ msvcrt ELF 7e1e5000-7e2ca000 Dwarf msvcp90 -PE 7e210000-7e2ca000 \ msvcp90 ELF 7e2ca000-7e2ec000 Deferred imm32 -PE 7e2d0000-7e2ec000 \ imm32 ELF 7e2ec000-7e3de000 Deferred oleaut32 -PE 7e300000-7e3de000 \ oleaut32 ELF 7e3de000-7e418000 Deferred winspool -PE 7e3f0000-7e418000 \ winspool ELF 7e418000-7e4f7000 Deferred comdlg32 -PE 7e420000-7e4f7000 \ comdlg32 ELF 7e4f7000-7e51f000 Deferred msacm32 -PE 7e500000-7e51f000 \ msacm32 ELF 7e51f000-7e5cc000 Deferred winmm -PE 7e530000-7e5cc000 \ winmm ELF 7e5cc000-7e641000 Deferred rpcrt4 -PE 7e5e0000-7e641000 \ rpcrt4 ELF 7e641000-7e749000 Deferred ole32 -PE 7e660000-7e749000 \ ole32 ELF 7e749000-7e841000 Deferred comctl32 -PE 7e750000-7e841000 \ comctl32 ELF 7e841000-7ea52000 Deferred shell32 -PE 7e850000-7ea52000 \ shell32 ELF 7ea52000-7eabc000 Deferred shlwapi -PE 7ea60000-7eabc000 \ shlwapi ELF 7eabc000-7ead5000 Deferred version -PE 7eac0000-7ead5000 \ version ELF 7ead5000-7eb35000 Deferred advapi32 -PE 7eae0000-7eb35000 \ advapi32 ELF 7eb35000-7ebf2000 Deferred gdi32 -PE 7eb40000-7ebf2000 \ gdi32 ELF 7ebf2000-7ed32000 Deferred user32 -PE 7ec00000-7ed32000 \ user32 ELF 7ed32000-7ed58000 Deferred mpr -PE 7ed40000-7ed58000 \ mpr ELF 7ed58000-7ed6e000 Deferred libz.so.1 ELF 7ed6e000-7eddd000 Deferred wininet -PE 7ed80000-7eddd000 \ wininet ELF 7eddd000-7ee0f000 Deferred ws2_32 -PE 7ede0000-7ee0f000 \ ws2_32 ELF 7ee0f000-7ee1c000 Deferred libnss_files.so.2 ELF 7ee1c000-7ee28000 Deferred libnss_nis.so.2 ELF 7ee28000-7ee42000 Deferred libnsl.so.1 ELF 7ee42000-7ee4b000 Deferred libnss_compat.so.2 ELF 7efd4000-7f000000 Deferred libm.so.6 ELF f74a3000-f74a7000 Deferred libxau.so.6 ELF f74a8000-f74ad000 Deferred libdl.so.2 ELF f74ad000-f7657000 Deferred libc.so.6 ELF f7658000-f7673000 Deferred libpthread.so.0 ELF f7675000-f767b000 Deferred libuuid.so.1 ELF f7682000-f77c4000 Dwarf libwine.so.1 ELF f77c6000-f77e8000 Deferred ld-linux.so.2 ELF f77e8000-f77e9000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 0000000e services.exe 0000001f 0 0000001e 0 00000015 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001c 0 00000019 0 00000014 0 00000013 0 0000001a plugplay.exe 00000020 0 0000001d 0 0000001b 0 00000037 explorer.exe 00000038 0 00000042 (D) C:\Program Files (x86)\Amazon\Kindle\Kindle.exe 00000043 0 <== System information: Wine build: wine-1.4 Platform: i386 (WOW64) Host system: Linux Host version: 3.8.11 How can this be fixed?

    Read the article

  • elffile: ELF Specific File Identification Utility

    - by user9154181
    Solaris 11 has a new standard user level command, /usr/bin/elffile. elffile is a variant of the file utility that is focused exclusively on linker related files: ELF objects, archives, and runtime linker configuration files. All other files are simply identified as "non-ELF". The primary advantage of elffile over the existing file utility is in the area of archives — elffile examines the archive members and can produce a summary of the contents, or per-member details. The impetus to add elffile to Solaris came from the effort to extend the format of Solaris archives so that they could grow beyond their previous 32-bit file limits. That work introduced a new archive symbol table format. Now that there was more than one possible format, I thought it would be useful if the file utility could identify which format a given archive is using, leading me to extend the file utility: % cc -c ~/hello.c % ar r foo.a hello.o % file foo.a foo.a: current ar archive, 32-bit symbol table % ar r -S foo.a hello.o % file foo.a foo.a: current ar archive, 64-bit symbol table In turn, this caused me to think about all the things that I would like the file utility to be able to tell me about an archive. In particular, I'd like to be able to know what's inside without having to unpack it. The end result of that train of thought was elffile. Much of the discussion in this article is adapted from the PSARC case I filed for elffile in December 2010: PSARC 2010/432 elffile Why file Is No Good For Archives And Yet Should Not Be Fixed The standard /usr/bin/file utility is not very useful when applied to archives. When identifying an archive, a user typically wants to know 2 things: Is this an archive? Presupposing that the archive contains objects, which is by far the most common use for archives, what platform are the objects for? Are they for sparc or x86? 32 or 64-bit? Some confusing combination from varying platforms? The file utility provides a quick answer to question (1), as it identifies all archives as "current ar archive". It does nothing to answer the more interesting question (2). To answer that question, requires a multi-step process: Extract all archive members Use the file utility on the extracted files, examine the output for each file in turn, and compare the results to generate a suitable summary description. Remove the extracted files It should be easier and more efficient to answer such an obvious question. It would be reasonable to extend the file utility to examine archive contents in place and produce a description. However, there are several reasons why I decided not to do so: The correct design for this feature within the file utility would have file examine each archive member in turn, applying its full abilities to each member. This would be elegant, but also represents a rather dramatic redesign and re-implementation of file. Archives nearly always contain nothing but ELF objects for a single platform, so such generality in the file utility would be of little practical benefit. It is best to avoid adding new options to standard utilities for which other implementations of interest exist. In the case of the file utility, one concern is that we might add an option which later appears in the GNU version of file with a different and incompatible meaning. Indeed, there have been discussions about replacing the Solaris file with the GNU version in the past. This may or may not be desirable, and may or may not ever happen. Either way, I don't want to preclude it. Examining archive members is an O(n) operation, and can be relatively slow with large archives. The file utility is supposed to be a very fast operation. I decided that extending file in this way is overkill, and that an investment in the file utility for better archive support would not be worth the cost. A solution that is more narrowly focused on ELF and other linker related files is really all that we need. The necessary code for doing this already exists within libelf. All that is missing is a small user-level wrapper to make that functionality available at the command line. In that vein, I considered adding an option for this to the elfdump utility. I examined elfdump carefully, and even wrote a prototype implementation. The added code is small and simple, but the conceptual fit with the rest of elfdump is poor. The result complicates elfdump syntax and documentation, definite signs that this functionality does not belong there. And so, I added this functionality as a new user level command. The elffile Command The syntax for this new command is elffile [-s basic | detail | summary] filename... Please see the elffile(1) manpage for additional details. To demonstrate how output from elffile looks, I will use the following files: FileDescription configA runtime linker configuration file produced with crle dwarf.oAn ELF object /etc/passwdA text file mixed.aArchive containing a mixture of ELF and non-ELF members mixed_elf.aArchive containing ELF objects for different machines not_elf.aArchive containing no ELF objects same_elf.aArchive containing a collection of ELF objects for the same machine. This is the most common type of archive. The file utility identifies these files as follows: % file config dwarf.o /etc/passwd mixed.a mixed_elf.a not_elf.a same_elf.a config: Runtime Linking Configuration 64-bit MSB SPARCV9 dwarf.o: ELF 64-bit LSB relocatable AMD64 Version 1 /etc/passwd: ascii text mixed.a: current ar archive, 32-bit symbol table mixed_elf.a: current ar archive, 32-bit symbol table not_elf.a: current ar archive same_elf.a: current ar archive, 32-bit symbol table By default, elffile uses its "summary" output style. This output differs from the output from the file utility in 2 significant ways: Files that are not an ELF object, archive, or runtime linker configuration file are identified as "non-ELF", whereas the file utility attempts further identification for such files. When applied to an archive, the elffile output includes a description of the archive's contents, without requiring member extraction or other additional steps. Applying elffile to the above files: % elffile config dwarf.o /etc/passwd mixed.a mixed_elf.a not_elf.a same_elf.a config: Runtime Linking Configuration 64-bit MSB SPARCV9 dwarf.o: ELF 64-bit LSB relocatable AMD64 Version 1 /etc/passwd: non-ELF mixed.a: current ar archive, 32-bit symbol table, mixed ELF and non-ELF content mixed_elf.a: current ar archive, 32-bit symbol table, mixed ELF content not_elf.a: current ar archive, non-ELF content same_elf.a: current ar archive, 32-bit symbol table, ELF 64-bit LSB relocatable AMD64 Version 1 The output for same_elf.a is of particular interest: The vast majority of archives contain only ELF objects for a single platform, and in this case, the default output from elffile answers both of the questions about archives posed at the beginning of this discussion, in a single efficient step. This makes elffile considerably more useful than file, within the realm of linker-related files. elffile can produce output in two other styles, "basic", and "detail". The basic style produces output that is the same as that from 'file', for linker-related files. The detail style produces per-member identification of archive contents. This can be useful when the archive contents are not homogeneous ELF object, and more information is desired than the summary output provides: % elffile -s detail mixed.a mixed.a: current ar archive, 32-bit symbol table mixed.a(dwarf.o): ELF 32-bit LSB relocatable 80386 Version 1 mixed.a(main.c): non-ELF content mixed.a(main.o): ELF 64-bit LSB relocatable AMD64 Version 1 [SSE]

    Read the article

  • Ancillary Objects: Separate Debug ELF Files For Solaris

    - by Ali Bahrami
    We introduced a new object ELF object type in Solaris 11 Update 1 called the Ancillary Object. This posting describes them, using material originally written during their development, the PSARC arc case, and the Solaris Linker and Libraries Manual. ELF objects contain allocable sections, which are mapped into memory at runtime, and non-allocable sections, which are present in the file for use by debuggers and observability tools, but which are not mapped or used at runtime. Typically, all of these sections exist within a single object file. Ancillary objects allow them to instead go into a separate file. There are different reasons given for wanting such a feature. One can debate whether the added complexity is worth the benefit, and in most cases it is not. However, one important case stands out — customers with very large 32-bit objects who are not ready or able to make the transition to 64-bits. We have customers who build extremely large 32-bit objects. Historically, the debug sections in these objects have used the stabs format, which is limited, but relatively compact. In recent years, the industry has transitioned to the powerful but verbose DWARF standard. In some cases, the size of these debug sections is large enough to push the total object file size past the fundamental 4GB limit for 32-bit ELF object files. The best, and ultimately only, solution to overly large objects is to transition to 64-bits. However, consider environments where: Hundreds of users may be executing the code on large shared systems. (32-bits use less memory and bus bandwidth, and on sparc runs just as fast as 64-bit code otherwise). Complex finely tuned code, where the original authors may no longer be available. Critical production code, that was expensive to qualify and bring online, and which is otherwise serving its intended purpose without issue. Users in these risk adverse and/or high scale categories have good reasons to push 32-bits objects to the limit before moving on. Ancillary objects offer these users a longer runway. Design The design of ancillary objects is intended to be simple, both to help human understanding when examining elfdump output, and to lower the bar for debuggers such as dbx to support them. The primary and ancillary objects have the same set of section headers, with the same names, in the same order (i.e. each section has the same index in both files). A single added section of type SHT_SUNW_ANCILLARY is added to both objects, containing information that allows a debugger to identify and validate both files relative to each other. Given one of these files, the ancillary section allows you to identify the other. Allocable sections go in the primary object, and non-allocable ones go into the ancillary object. A small set of non-allocable objects, notably the symbol table, are copied into both objects. As noted above, most sections are only written to one of the two objects, but both objects have the same section header array. The section header in the file that does not contain the section data is tagged with the SHF_SUNW_ABSENT section header flag to indicate its placeholder status. Compiler writers and others who produce objects can set the SUNW_SHF_PRIMARY section header flag to mark non-allocable sections that should go to the primary object rather than the ancillary. If you don't request an ancillary object, the Solaris ELF format is unchanged. Users who don't use ancillary objects do not pay for the feature. This is important, because they exist to serve a small subset of our users, and must not complicate the common case. If you do request an ancillary object, the runtime behavior of the primary object will be the same as that of a normal object. There is no added runtime cost. The primary and ancillary object together represent a logical single object. This is facilitated by the use of a single set of section headers. One can easily imagine a tool that can merge a primary and ancillary object into a single file, or the reverse. (Note that although this is an interesting intellectual exercise, we don't actually supply such a tool because there's little practical benefit above and beyond using ld to create the files). Among the benefits of this approach are: There is no need for per-file symbol tables to reflect the contents of each file. The same symbol table that would be produced for a standard object can be used. The section contents are identical in either case — there is no need to alter data to accommodate multiple files. It is very easy for a debugger to adapt to these new files, and the processing involved can be encapsulated in input/output routines. Most of the existing debugger implementation applies without modification. The limit of a 4GB 32-bit output object is now raised to 4GB of code, and 4GB of debug data. There is also the future possibility (not currently supported) to support multiple ancillary objects, each of which could contain up to 4GB of additional debug data. It must be noted however that the 32-bit DWARF debug format is itself inherently 32-bit limited, as it uses 32-bit offsets between debug sections, so the ability to employ multiple ancillary object files may not turn out to be useful. Using Ancillary Objects (From the Solaris Linker and Libraries Guide) By default, objects contain both allocable and non-allocable sections. Allocable sections are the sections that contain executable code and the data needed by that code at runtime. Non-allocable sections contain supplemental information that is not required to execute an object at runtime. These sections support the operation of debuggers and other observability tools. The non-allocable sections in an object are not loaded into memory at runtime by the operating system, and so, they have no impact on memory use or other aspects of runtime performance no matter their size. For convenience, both allocable and non-allocable sections are normally maintained in the same file. However, there are situations in which it can be useful to separate these sections. To reduce the size of objects in order to improve the speed at which they can be copied across wide area networks. To support fine grained debugging of highly optimized code requires considerable debug data. In modern systems, the debugging data can easily be larger than the code it describes. The size of a 32-bit object is limited to 4 Gbytes. In very large 32-bit objects, the debug data can cause this limit to be exceeded and prevent the creation of the object. To limit the exposure of internal implementation details. Traditionally, objects have been stripped of non-allocable sections in order to address these issues. Stripping is effective, but destroys data that might be needed later. The Solaris link-editor can instead write non-allocable sections to an ancillary object. This feature is enabled with the -z ancillary command line option. $ ld ... -z ancillary[=outfile] ...By default, the ancillary file is given the same name as the primary output object, with a .anc file extension. However, a different name can be provided by providing an outfile value to the -z ancillary option. When -z ancillary is specified, the link-editor performs the following actions. All allocable sections are written to the primary object. In addition, all non-allocable sections containing one or more input sections that have the SHF_SUNW_PRIMARY section header flag set are written to the primary object. All remaining non-allocable sections are written to the ancillary object. The following non-allocable sections are written to both the primary object and ancillary object. .shstrtab The section name string table. .symtab The full non-dynamic symbol table. .symtab_shndx The symbol table extended index section associated with .symtab. .strtab The non-dynamic string table associated with .symtab. .SUNW_ancillary Contains the information required to identify the primary and ancillary objects, and to identify the object being examined. The primary object and all ancillary objects contain the same array of sections headers. Each section has the same section index in every file. Although the primary and ancillary objects all define the same section headers, the data for most sections will be written to a single file as described above. If the data for a section is not present in a given file, the SHF_SUNW_ABSENT section header flag is set, and the sh_size field is 0. This organization makes it possible to acquire a full list of section headers, a complete symbol table, and a complete list of the primary and ancillary objects from either of the primary or ancillary objects. The following example illustrates the underlying implementation of ancillary objects. An ancillary object is created by adding the -z ancillary command line option to an otherwise normal compilation. The file utility shows that the result is an executable named a.out, and an associated ancillary object named a.out.anc. $ cat hello.c #include <stdio.h> int main(int argc, char **argv) { (void) printf("hello, world\n"); return (0); } $ cc -g -zancillary hello.c $ file a.out a.out.anc a.out: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, ancillary object a.out.anc a.out.anc: ELF 32-bit LSB ancillary 80386 Version 1, primary object a.out $ ./a.out hello worldThe resulting primary object is an ordinary executable that can be executed in the usual manner. It is no different at runtime than an executable built without the use of ancillary objects, and then stripped of non-allocable content using the strip or mcs commands. As previously described, the primary object and ancillary objects contain the same section headers. To see how this works, it is helpful to use the elfdump utility to display these section headers and compare them. The following table shows the section header information for a selection of headers from the previous link-edit example. Index Section Name Type Primary Flags Ancillary Flags Primary Size Ancillary Size 13 .text PROGBITS ALLOC EXECINSTR ALLOC EXECINSTR SUNW_ABSENT 0x131 0 20 .data PROGBITS WRITE ALLOC WRITE ALLOC SUNW_ABSENT 0x4c 0 21 .symtab SYMTAB 0 0 0x450 0x450 22 .strtab STRTAB STRINGS STRINGS 0x1ad 0x1ad 24 .debug_info PROGBITS SUNW_ABSENT 0 0 0x1a7 28 .shstrtab STRTAB STRINGS STRINGS 0x118 0x118 29 .SUNW_ancillary SUNW_ancillary 0 0 0x30 0x30 The data for most sections is only present in one of the two files, and absent from the other file. The SHF_SUNW_ABSENT section header flag is set when the data is absent. The data for allocable sections needed at runtime are found in the primary object. The data for non-allocable sections used for debugging but not needed at runtime are placed in the ancillary file. A small set of non-allocable sections are fully present in both files. These are the .SUNW_ancillary section used to relate the primary and ancillary objects together, the section name string table .shstrtab, as well as the symbol table.symtab, and its associated string table .strtab. It is possible to strip the symbol table from the primary object. A debugger that encounters an object without a symbol table can use the .SUNW_ancillary section to locate the ancillary object, and access the symbol contained within. The primary object, and all associated ancillary objects, contain a .SUNW_ancillary section that allows all the objects to be identified and related together. $ elfdump -T SUNW_ancillary a.out a.out.anc a.out: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0x8724 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 a.out.anc: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0xfbe2 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 The ancillary sections for both objects contain the same number of elements, and are identical except for the first element. Each object, starting with the primary object, is introduced with a MEMBER element that gives the file name, followed by a CHECKSUM that identifies the object. In this example, the primary object is a.out, and has a checksum of 0x8724. The ancillary object is a.out.anc, and has a checksum of 0xfbe2. The first element in a .SUNW_ancillary section, preceding the MEMBER element for the primary object, is always a CHECKSUM element, containing the checksum for the file being examined. The presence of a .SUNW_ancillary section in an object indicates that the object has associated ancillary objects. The names of the primary and all associated ancillary objects can be obtained from the ancillary section from any one of the files. It is possible to determine which file is being examined from the larger set of files by comparing the first checksum value to the checksum of each member that follows. Debugger Access and Use of Ancillary Objects Debuggers and other observability tools must merge the information found in the primary and ancillary object files in order to build a complete view of the object. This is equivalent to processing the information from a single file. This merging is simplified by the primary object and ancillary objects containing the same section headers, and a single symbol table. The following steps can be used by a debugger to assemble the information contained in these files. Starting with the primary object, or any of the ancillary objects, locate the .SUNW_ancillary section. The presence of this section identifies the object as part of an ancillary group, contains information that can be used to obtain a complete list of the files and determine which of those files is the one currently being examined. Create a section header array in memory, using the section header array from the object being examined as an initial template. Open and read each file identified by the .SUNW_ancillary section in turn. For each file, fill in the in-memory section header array with the information for each section that does not have the SHF_SUNW_ABSENT flag set. The result will be a complete in-memory copy of the section headers with pointers to the data for all sections. Once this information has been acquired, the debugger can proceed as it would in the single file case, to access and control the running program. Note - The ELF definition of ancillary objects provides for a single primary object, and an arbitrary number of ancillary objects. At this time, the Oracle Solaris link-editor only produces a single ancillary object containing all non-allocable sections. This may change in the future. Debuggers and other observability tools should be written to handle the general case of multiple ancillary objects. ELF Implementation Details (From the Solaris Linker and Libraries Guide) To implement ancillary objects, it was necessary to extend the ELF format to add a new object type (ET_SUNW_ANCILLARY), a new section type (SHT_SUNW_ANCILLARY), and 2 new section header flags (SHF_SUNW_ABSENT, SHF_SUNW_PRIMARY). In this section, I will detail these changes, in the form of diffs to the Solaris Linker and Libraries manual. Part IV ELF Application Binary Interface Chapter 13: Object File Format Object File Format Edit Note: This existing section at the beginning of the chapter describes the ELF header. There's a table of object file types, which now includes the new ET_SUNW_ANCILLARY type. e_type Identifies the object file type, as listed in the following table. NameValueMeaning ET_NONE0No file type ET_REL1Relocatable file ET_EXEC2Executable file ET_DYN3Shared object file ET_CORE4Core file ET_LOSUNW0xfefeStart operating system specific range ET_SUNW_ANCILLARY0xfefeAncillary object file ET_HISUNW0xfefdEnd operating system specific range ET_LOPROC0xff00Start processor-specific range ET_HIPROC0xffffEnd processor-specific range Sections Edit Note: This overview section defines the section header structure, and provides a high level description of known sections. It was updated to define the new SHF_SUNW_ABSENT and SHF_SUNW_PRIMARY flags and the new SHT_SUNW_ANCILLARY section. ... sh_type Categorizes the section's contents and semantics. Section types and their descriptions are listed in Table 13-5. sh_flags Sections support 1-bit flags that describe miscellaneous attributes. Flag definitions are listed in Table 13-8. ... Table 13-5 ELF Section Types, sh_type NameValue . . . SHT_LOSUNW0x6fffffee SHT_SUNW_ancillary0x6fffffee . . . ... SHT_LOSUNW - SHT_HISUNW Values in this inclusive range are reserved for Oracle Solaris OS semantics. SHT_SUNW_ANCILLARY Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section. ... Table 13-8 ELF Section Attribute Flags NameValue . . . SHF_MASKOS0x0ff00000 SHF_SUNW_NODISCARD0x00100000 SHF_SUNW_ABSENT0x00200000 SHF_SUNW_PRIMARY0x00400000 SHF_MASKPROC0xf0000000 . . . ... SHF_SUNW_ABSENT Indicates that the data for this section is not present in this file. When ancillary objects are created, the primary object and any ancillary objects, will all have the same section header array, to facilitate merging them to form a complete view of the object, and to allow them to use the same symbol tables. Each file contains a subset of the section data. The data for allocable sections is written to the primary object while the data for non-allocable sections is written to an ancillary file. The SHF_SUNW_ABSENT flag is used to indicate that the data for the section is not present in the object being examined. When the SHF_SUNW_ABSENT flag is set, the sh_size field of the section header must be 0. An application encountering an SHF_SUNW_ABSENT section can choose to ignore the section, or to search for the section data within one of the related ancillary files. SHF_SUNW_PRIMARY The default behavior when ancillary objects are created is to write all allocable sections to the primary object and all non-allocable sections to the ancillary objects. The SHF_SUNW_PRIMARY flag overrides this behavior. Any output section containing one more input section with the SHF_SUNW_PRIMARY flag set is written to the primary object without regard for its allocable status. ... Two members in the section header, sh_link, and sh_info, hold special information, depending on section type. Table 13-9 ELF sh_link and sh_info Interpretation sh_typesh_linksh_info . . . SHT_SUNW_ANCILLARY The section header index of the associated string table. 0 . . . Special Sections Edit Note: This section describes the sections used in Solaris ELF objects, using the types defined in the previous description of section types. It was updated to define the new .SUNW_ancillary (SHT_SUNW_ANCILLARY) section. Various sections hold program and control information. Sections in the following table are used by the system and have the indicated types and attributes. Table 13-10 ELF Special Sections NameTypeAttribute . . . .SUNW_ancillarySHT_SUNW_ancillaryNone . . . ... .SUNW_ancillary Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section for details. ... Ancillary Section Edit Note: This new section provides the format reference describing the layout of a .SUNW_ancillary section and the meaning of the various tags. Note that these sections use the same tag/value concept used for dynamic and capabilities sections, and will be familiar to anyone used to working with ELF. In addition to the primary output object, the Solaris link-editor can produce one or more ancillary objects. Ancillary objects contain non-allocable sections that would normally be written to the primary object. When ancillary objects are produced, the primary object and all of the associated ancillary objects contain a SHT_SUNW_ancillary section, containing information that identifies these related objects. Given any one object from such a group, the ancillary section provides the information needed to identify and interpret the others. This section contains an array of the following structures. See sys/elf.h. typedef struct { Elf32_Word a_tag; union { Elf32_Word a_val; Elf32_Addr a_ptr; } a_un; } Elf32_Ancillary; typedef struct { Elf64_Xword a_tag; union { Elf64_Xword a_val; Elf64_Addr a_ptr; } a_un; } Elf64_Ancillary; For each object with this type, a_tag controls the interpretation of a_un. a_val These objects represent integer values with various interpretations. a_ptr These objects represent file offsets or addresses. The following ancillary tags exist. Table 13-NEW1 ELF Ancillary Array Tags NameValuea_un ANC_SUNW_NULL0Ignored ANC_SUNW_CHECKSUM1a_val ANC_SUNW_MEMBER2a_ptr ANC_SUNW_NULL Marks the end of the ancillary section. ANC_SUNW_CHECKSUM Provides the checksum for a file in the c_val element. When ANC_SUNW_CHECKSUM precedes the first instance of ANC_SUNW_MEMBER, it provides the checksum for the object from which the ancillary section is being read. When it follows an ANC_SUNW_MEMBER tag, it provides the checksum for that member. ANC_SUNW_MEMBER Specifies an object name. The a_ptr element contains the string table offset of a null-terminated string, that provides the file name. An ancillary section must always contain an ANC_SUNW_CHECKSUM before the first instance of ANC_SUNW_MEMBER, identifying the current object. Following that, there should be an ANC_SUNW_MEMBER for each object that makes up the complete set of objects. Each ANC_SUNW_MEMBER should be followed by an ANC_SUNW_CHECKSUM for that object. A typical ancillary section will therefore be structured as: TagMeaning ANC_SUNW_CHECKSUMChecksum of this object ANC_SUNW_MEMBERName of object #1 ANC_SUNW_CHECKSUMChecksum for object #1 . . . ANC_SUNW_MEMBERName of object N ANC_SUNW_CHECKSUMChecksum for object N ANC_SUNW_NULL An object can therefore identify itself by comparing the initial ANC_SUNW_CHECKSUM to each of the ones that follow, until it finds a match. Related Other Work The GNU developers have also encountered the need/desire to support separate debug information files, and use the solution detailed at http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html. At the current time, the separate debug file is constructed by building the standard object first, and then copying the debug data out of it in a separate post processing step, Hence, it is limited to a total of 4GB of code and debug data, just as a single object file would be. They are aware of this, and I have seen online comments indicating that they may add direct support for generating these separate files to their link-editor. It is worth noting that the GNU objcopy utility is available on Solaris, and that the Studio dbx debugger is able to use these GNU style separate debug files even on Solaris. Although this is interesting in terms giving Linux users a familiar environment on Solaris, the 4GB limit means it is not an answer to the problem of very large 32-bit objects. We have also encountered issues with objcopy not understanding Solaris-specific ELF sections, when using this approach. The GNU community also has a current effort to adapt their DWARF debug sections in order to move them to separate files before passing the relocatable objects to the linker. The details of Project Fission can be found at http://gcc.gnu.org/wiki/DebugFission. The goal of this project appears to be to reduce the amount of data seen by the link-editor. The primary effort revolves around moving DWARF data to separate .dwo files so that the link-editor never encounters them. The details of modifying the DWARF data to be usable in this form are involved — please see the above URL for details.

    Read the article

  • Building elf within Eclipse

    - by BSchlinker
    Hey guys, I'm having trouble building an Elf file within Eclipse. It seems that everytime I build, a PE / portable executable for windows is created. I've gone into the Binary Parser section and checked Elf Parser while making sure that everything else is unchecked. However, I continue to end up with a PE which I cannot run on Linux. Any ideas? Thanks

    Read the article

  • Converting kernel image from ELF to PE

    - by Frank Miller
    I am using Msys to build a home brew kernel that I wrote under Linux. Linux used ELF for its binary format and Msys uses PE. I have the source setup to allow it to be booted by Grub using the Multiboot spec. At the end of the build, I get some undefined symbols: init.o:init.S:(.text+0x14): undefined reference to `edata' main.o:main.c:(.text+0x121): undefined reference to `_alloca' main.o:main.c:(.text+0x126): undefined reference to `__main' ../../lib\libkern.a(mem.o):mem.c:(.text+0x242): undefined reference to `_end' ../../lib\libkern.a(mem.o):mem.c:(.text+0x323): undefined reference to `_end' These appear to be ELF oriented symbols. If anyone can advise me on how these should be dealt with in the PE world, e.g. if there are equivalents, it would help me out a lot!

    Read the article

  • Building elf within Eclipse within Windows

    - by BSchlinker
    Hey guys, I'm having trouble building an Elf file within Eclipse within Windows. It seems that everytime I build, a PE / portable executable for windows is created. I've gone into the Binary Parser section and checked Elf Parser while making sure that everything else is unchecked. However, I continue to end up with a PE which I cannot run on Linux. For clarification, I'm using the Linux GCC toolchain within Eclipse. I've attempted a reinstall of Cygwin -- still experiencing the same issues. Any ideas? Thanks

    Read the article

  • Kernel dealing with the section headers in an ELF

    - by uki
    I recently read that the kernel and the dynamic loader mostly deal with the program header tables in an ELF file and that assemblers, compilers and linkers deal with the section header tables. The number of program header tables and section header tables are mentioned in the ELF header in fields named e_phnum and e_shnum respectively. e_phnum is two bytes in size, so if the number of program headers is 65535, we use a scheme known as extended numbering where, e_phnum is set to 0xffff and sh_link field of the zeroth section header table holds the actual count. My doubt is : If the count of program headers exceeds 65535, does that mean the kernel and/or the dynamic loader end up having to read the section table?

    Read the article

  • Access ELF string table section header

    - by idealistikz
    Assume: Elf_Section_Header *sectionHeaderTable //points to the start of a ELF section header table Elf_Section_Header *symtabHeader //points to the start of the symtab section header Why doesn't the following point me to the associated string table section header? Elf_Section_Header *strTabSectionHeader = (Elf_Section_Header *)((char *)sectionHeaderTable + (symtabHeader-strtab_index)); 'strTabSectionHeader-type == SHT_STRTAB' is equal to false How should I point ot the strTabSectionHeader?

    Read the article

  • '/usr/lib/mozilla/plugins/npPluginTest.so' is not an ELF executable for sh

    - by rakesh nair
    I have created NPAPI plugin, which is workig fine on linux where I have created the .so file but when I deployed this plugin on our production device where we have linux environment with limited resources(due to performance constraints) , following error is thrown '/usr/lib/mozilla/plugins/npPluginTest.so' is not an ELF executable for sh FYI:so file created on 32bit linux box. how can I resolve this issue?

    Read the article

  • Packing a file into an ELF executable

    - by Pierre Bourdon
    Hello, I'm currently looking for a way to add data to an already compiled ELF executable, i.e. embedding a file into the executable without recompiling it. I could easily do that by using cat myexe mydata > myexe_with_mydata, but I couldn't access the data from the executable because I don't know the size of the original executable. Does anyone have an idea of how I could implement this ? I thought of adding a section to the executable or using a special marker (0xBADBEEFC0FFEE for example) to detect the beginning of the data in the executable, but I do not know if there is a more beautiful way to do it. Thanks in advance.

    Read the article

  • ELF: linking: Why do I get undefined references in .so files

    - by ki.lya.online.fr
    Hi, I'm trying to build a program against wxWidgets, and I get a linker error. I'd like to really understand what it means. The error is: /usr/lib/libwx_baseu-2.8.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' What I don't understand is why the error is at libwx_baseu-2.8.so. I thought that .so files had all its symbols resolved, contrary to .o files that still need linking. When I ldd the .so, I get can resolve all its linked libraries, so there is no problem there: $ ldd /usr/lib/libwx_baseu-2.8.so linux-gate.so.1 => (0x00476000) libz.so.1 => /lib/libz.so.1 (0x00d9c000) libdl.so.2 => /lib/libdl.so.2 (0x002a8000) libm.so.6 => /lib/libm.so.6 (0x00759000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x002ad000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0068d000) libpthread.so.0 => /lib/libpthread.so.0 (0x006f0000) libc.so.6 => /lib/libc.so.6 (0x00477000) /lib/ld-linux.so.2 (0x007f6000) Does it means that the .so file was not compiled correctly (in that case, it's a bug in my distribution package) or does it means that there are missing libraries on the linker command line for my particular program? Additionally, do you know how I can get a list on undefined symbols in an ELF file. I tried readelf -s but I can't find the missing symbol. Thank you. Mildred

    Read the article

  • How can I find the size of a ELF file/image with Header information?

    - by fasil
    I need to find the size of an elf image for some computation. I have tried with the readelf utility on linux which gives the informations about the headers and section. I need to have the exact file size of the elf(on the whole). How do I find the size of the ELF from the header information or Is there any other means to find the size of an elf without reading the full image.

    Read the article

  • Elf: Dump symbol value in BSS, DATA or RODATA?

    - by noloader
    I have a ELF shared object with a symbol initialized to a value. I want to know what the value of a symbol is. I know objdump -T will give me the symbol's address and length but I need the value: $ arm-linux-androideabi-objdump -T libcrypto.so.1.0.0 | grep -i FIPS_signature 001a9668 g DO .bss 00000014 FIPS_signature However, hexdump knows nothing about ELF sections, offsets and virtual addresses, so I can't use the information: $ hexdump -v -x -n 0x14 -s 0x001a9668 libcrypto.so.1.0.0 $ How do I dump the value of the symbol? Jeff

    Read the article

  • Steam, launching Team Fortress 2: libGL.so.1: wrong ELF class: ELFCLASS64

    - by stefanhgm
    After I got Steam running with the workaround mentioned here, I've got nearly the same problem when launching Team Fortress 2. After starting it from Steam the "Launcher" pops up and after a few seconds it disappears with the following error in the terminal: /home/user/Steam/SteamApps/steamuser/Team Fortress 2/hl2_linux: error while loading shared libraries: libGL.so.1: wrong ELF class: ELFCLASS64 Game removed: AppID 440 "Team Fortress 2", ProcID 5299 saving roaming config store to 'sharedconfig.vdf' roaming config store 2 saved successfully Because of the similarity with the workaround I used before, I tried to execute: export LD_LIBRARY_PATH=/usr/lib32:$LD_LIBRARY_PATH directly before launching the game, but there is no difference.

    Read the article

  • How do .so files avoid problems associated with passing header-only templates like MS dll files have?

    - by Doug T.
    Based on the discussion around this question. I'd like to know how .so files/the ELF format/the gcc toolchain avoid problems passing classes defined purely in header files (like the std library). According to Jan in that answer, the dynamic linker/loader only picks one version of such a class to load if its defined in two .so files. So if two .so files have two definitions, perhaps with different compiler options/etc, the dynamic linker can pick one to use. Is this correct? How does this work with inlining? For example, MSVC inlines templates aggressively. This makes the solution I describe above untenable for dlls. Does Gcc never inline header-only templates like the std library as MSVC does? If so wouldn't that make the functionality of ELF described above ineffective in these cases?

    Read the article

  • CentOS5 python wrong ELF class: ELFCLASS32

    - by user788171
    Has anybody ever encountered this wrong ELF class error? The failure is provided in more detail below: [root@nocloud ~]# system-config-users Traceback (most recent call last): File "/usr/share/system-config-users/system-config-users.py", line 25, in ? import libuser ImportError: /usr/lib/python2.4/site-packages/libusermodule.so: wrong ELF class: ELFCLASS32 Can anybody tell me how I might possibly be able to fix this? It looks like python broke on my server.

    Read the article

  • Why are functions loaded at aligned addresses in x86 Linux for elf executables?

    - by user344787
    Hi, I've been looking at Linux elf executables on x86, mostly using IDA but also gdb. One thing I've noticed is functions are always loaded at word aligned addresses? Anybody knows the reason of that? I am not aware of any requirement of x86 instructions to start at aligned addresses. And it cannot be due to page alignment cause the page boundary can still be anywhere within the function. I would appreciate any insight at all. Thanks.

    Read the article

1 2 3 4 5 6 7  | Next Page >