Opened 14 years ago

Closed 14 years ago

#104 closed defect (invalid)

emximp: Processes aliased exports in the wrong way

Reported by: froloff Owned by: bird
Priority: normal Milestone: libc-0.6.2
Component: emx Version: 0.6
Severity: normal Keywords: emximp

Description (last modified by bird)

emximp create wrong function name, while converted def file, provided alias name in EXPORT section. For example, lines in input .def file

	zlibVersion = _zlibVersion
	deflate = _deflate

will cause the following text in output .imp file (same for .a and .lib):

; -------- zlib2.lib --------
zlibVersion            ZLIB2    _zlibVersion ?
deflate                ZLIB2    _deflate ?

While the destination shall looks like this:

; -------- zlib2.lib --------
zlibVersion             ZLIB2    zlibVersion ?
deflate                 ZLIB2    deflate ?

The reason of this bug in emx\src\libmoddef\moddef2.c Patch provided in attach. This also emxomfld and emxbind. Some changes also preferable in weak.c, function symAddExport(), while parsing def file.

Attachments (1) (530 bytes) - added by froloff 14 years ago.

Download all attachments as: .zip

Change History (3)

Changed 14 years ago by froloff

Attachment: added

comment:1 Changed 14 years ago by bird

Description: modified (diff)
Keywords: emximp added
Milestone: libc-0.6libc-0.6.2
Summary: emximp process def files with alias names in wrong wayemximp: Processes aliased exports in the wrong way
Type: defect
Version: 1.10.6

Froloff, the imp output shall be:

; -------- zlib2.lib --------
zlibVersion             ZLIB2    zlibVersion ?
deflate                 ZLIB2    deflate ?


; -------- zlib2.lib --------
_zlibVersion            ZLIB2    zlibVersion ?
_deflate                ZLIB2    deflate ?

Also, I've split out the weakld complaint into #115. That's an entirely different matter and has nothing to do with emximp. I'm not entirely sure what this problem has to do with emxomfld and emximp though, I'll try figure out what you mean...

comment:2 Changed 14 years ago by bird

Resolution: invalid
Status: newclosed

On second glance, the above comment is wrong. The current .imp output is 100% correct in respect to the names, there is nothing broken there. The patch is also wrong. emximp works perfectly for .def->.imp conversions. I've tested the emximp output with -Zomf links and it works perfectly.

But, it turns out that emxbind/emximp doesn't agree on how the N_IMP2 is supposed to be read. I'm creating a new defect for that since this one is completely messed up with reporting multiple problems in different modules and invalid reports/patches.

<rant> I'm a bit annoyed because instead of describing the actual problem here, the defect only describes some incorrect fixes and bitches about unrelated things. I've wasted more than an hour on figuring out what was actually the problem scenario here.

Please, give me decent bug reports! A decent bug reports includes a reproduction scenario and/or a description of the observed symptoms. If you know what the ultimate explanation for the symptom include that in the description, if you're not certain add it as a comment.

But please, do NOT even bother to submit patches which aren't properly tested or are addressing problems you don't quite understand. It's wasting my time and that's something that pisses me off. Instead just give me a decent report and we can discuss the cause here in the ticket system, on the mailing list or on irc.</rant>

Note: See TracTickets for help on using tickets.