From: stefan <st...@lk...> - 2000-11-07 16:29:39
|
hello mingw'ers, i finally got the new gcc-2.95.2-1 and had another try. seems like it is still busted... when linking everything with the new ld release i got lots of informational messages whats going on. that is of no use for the user, but maybe for the developer. it all went through now, but the the final binary is broken somehow. this is a short excerpt from it: ---- 8< ------------ There is an export table in .edata at 0x10018000 The Export Tables (interpreted .edata section contents) Export Flags 0 Time/Date stamp 3a07f15c Major/Minor 0/0 Name 00018c8a re237 Ordinal Base 1 Number in: Export Address Table 0000013d [Name Pointer/Ordinal] Table 0000013d Table Addresses Export Address Table 00018028 Name Pointer Table 0001851c Ordinal Table 00018a10 --> bad Name . . . [Ordinal/Name Pointer] Table [ 0] a [ 0] a [ 1] cl . --> bad name pointer . . [ 21] previous_history [ 0] read_history [ 22] read_history_range [ 0] readline [ 23] remove_history --> bad ordinals ---- >8 ------------ and so on. there is something strange... and this should not be like it is. the output has been produced by "objdump -p" which fails to complete in a segfault finally in the libbfd*.dll. *sigh* what is wrong here ? please help me, st...@lk... |
From: Paul S. <pa...@is...> - 2000-11-08 01:11:26
|
Hello stefan, stefan <st...@lk...> wrote on Tuesday, November 07, 2000: s> hello mingw'ers, s> i finally got the new gcc-2.95.2-1 and had another try. seems like it is s> still busted... when linking everything with the new ld release i got lots s> of informational messages whats going on. that is of no use for the user, s> but maybe for the developer. For detailed bugreport. And it's planly written in relnotes/changelog that it's pre-alpha. And yes, it has known problems for now. And your report seem to be about one of them. I'll put up new release as soon as I'll lash that debug output somehow. s> . s> [ 21] previous_history s> [ 0] read_history s> [ 22] read_history_range s> [ 0] readline s> [ 23] remove_history -->> bad ordinals -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: stefan <st...@lk...> - 2000-11-10 11:47:20
|
On Wed, 8 Nov 2000, Paul Sokolovsky wrote: > For detailed bugreport. And it's planly written in > relnotes/changelog that it's pre-alpha. And yes, it has known problems > for now. And your report seem to be about one of them. I'll put up new > release as soon as I'll lash that debug output somehow. Hello Paul, i tested the new release from 2000/11/08 and the export thingie has been fixed. The dll gets created without problems. But i got another "problem": I tried to compile following code: #include <stdio.h> extern char *rl_library_version; extern char* readline(char*); main() { readline("read a line >"); printf("%s\n", rl_library_version ? rl_library_version : "0"); exit(0); } and got a valid binary via (with the readline.dll only in current dir): $ gcc -o rlver.exe rlver.c -I. -L. -lreadline The function call readline() works fine, but the access to the char* does not work. The program crashes with segfault. If i declared rl_library_version "__declspec(dllimport)" it is ok, but that was just, what you intended to leave with the new ld version. Is that correct ? Maybe there are even a more problems: When i "objdump -p readline.dll" the program crashes either. Here is the gdb output of it. I hope this helps a bit... . . . reloc 2172 offset 0 [26800000] ABSOLUTE reloc 2173 offset 0 [26800000] ABSOLUTE Program received signal SIGSEGV, Segmentation fault. bfd_getl16 (addr=0x2577000 <Address 0x2577000 out of bounds>) at libbfd.c:952 952 libbfd.c: No such file or directory. (gdb) bt bt #0 bfd_getl16 (addr=0x2577000 <Address 0x2577000 out of bounds>) at libbfd.c:952 #1 0x6899cabf in pe_print_reloc (abfd=0x26806e0, vfile=0x78037c68) at peigen.c:1743 #2 0x6899d422 in _bfd_pe_print_private_bfd_data_common (abfd=0x26806e0, vfile=0x78037c68) at peigen.c:1880 #3 0x689a2284 in pe_print_private_bfd_data (abfd=0x26806e0, vfile=0x78037c68) at peicode.h:389 #4 0x404f11 in dump_bfd_private_header () #5 0x404fe2 in dump_bfd () #6 0x405222 in display_bfd () #7 0x40533a in display_file () Anyway, the new ld almostly feels like linking to lib*.so's under linux if it works correctly sometimes. Good job so far !! I have always been confused by all this import-library/__declspec() stuff, but thus it's getting much easier. Thank you Paul. st...@lk... |
From: Paul S. <pa...@is...> - 2000-11-11 09:24:10
|
Hello stefan, stefan <st...@lk...> wrote on Friday, November 10, 2000: s> #include <stdio.h> s> extern char *rl_library_version; s> extern char* readline(char*); s> main() s> { s> readline("read a line >"); s> printf("%s\n", rl_library_version ? rl_library_version : "0"); s> exit(0); s> } s> and got a valid binary via (with the readline.dll only in current dir): s> $ gcc -o rlver.exe rlver.c -I. -L. -lreadline s> The function call readline() works fine, but the access to the char* does s> not work. The program crashes with segfault. If i declared s> rl_library_version "__declspec(dllimport)" it is ok, but that was just, s> what you intended to leave with the new ld version. Is that correct ? Make sure that you: link against implib (not dll). That dll is built with my ld. If that is the case, please be ready to provide testcase for examination. s> Maybe there are even a more problems: When i "objdump -p readline.dll" the s> program crashes either. Here is the gdb output of it. I hope this helps s> a bit... This is known problem with objdump's showing auto-import files, to be fixed. s> Anyway, the new ld almostly feels like linking to lib*.so's under linux if s> it works correctly sometimes. Good job so far !! I have always been s> confused by all this import-library/__declspec() stuff, but thus it's s> getting much easier. Thank you Paul. Anyway, job's far from being polished. For example, linking directly against DLL *won't* work correctly for data symbols. Neither it can be done fully correct in principle (unless gcc output changed). Finally, it is not as useful as it seems - DLLs *should* contain version mark, and writing something like -lfoo-0.1.2 is not so cool indeed. On unix systems, this problem is solved with symlinks, on win32, implib bears the *same* meaning as those symlinks, so I prefer to stick with implibs, at least for now. s> st...@lk... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: stefan <st...@lk...> - 2000-11-11 13:25:02
Attachments:
readline.mft
readline.ver
|
Hi Paul, On Sat, 11 Nov 2000, Paul Sokolovsky wrote: > s> The function call readline() works fine, but the access to the char* does > s> not work. The program crashes with segfault. If i declared > s> rl_library_version "__declspec(dllimport)" it is ok, but that was just, > s> what you intended to leave with the new ld version. Is that correct ? > > Make sure that you: link against implib (not dll). That dll is > built with my ld. If that is the case, please be ready to provide > testcase for examination. I built it with the new ld. See below. > s> Maybe there are even a more problems: When i "objdump -p readline.dll" the > s> program crashes either. Here is the gdb output of it. I hope this helps > s> a bit... > > This is known problem with objdump's showing auto-import files, to > be fixed. Waiting patiently... > s> Anyway, the new ld almostly feels like linking to lib*.so's under linux if > s> it works correctly sometimes. Good job so far !! I have always been > s> confused by all this import-library/__declspec() stuff, but thus it's > s> getting much easier. Thank you Paul. > > Anyway, job's far from being polished. For example, linking > directly against DLL *won't* work correctly for data symbols. Neither it > can be done fully correct in principle (unless gcc output changed). > Finally, it is not as useful as it seems - DLLs *should* contain > version mark, and writing something like -lfoo-0.1.2 is not so cool > indeed. On unix systems, this problem is solved with symlinks, on > win32, implib bears the *same* meaning as those symlinks, so I prefer > to stick with implibs, at least for now. Ok. Good to know that it *won't* work. Thus i tried it with the import library (also built with new ld)... and it finally worked. Without these __declspec() thingies. Great !!!!!! Then i tried to pack my readline 4.1 port for MinGW as you always do. Within the attachment you'll find the files from the manifest directory. Please tell me if this is in any way what you want. If so, then i can tell where to get the package itself and add it to the mingwrep project or you do let me do this myself. If you approved my "contribution" i could pack all the other packages i annouced some mails before, too. Thanks in advance, st...@lk... |