After a long and tedious grind I am pleased to announce version 2.0 of mkelfImage. New features. - One single binary - Itanium support - All of the code is in C. - New and exciting easter eggs (err bugs can you find them before I do?...)
Available at: ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.0.tar.gz
rpms can be built with rpm -ta mkelfImage-2.0.tar.gz alien will make perfectly serviceable debs from those...
The decision to go with pure C is that it is both relatively portable, and it reduces maintenance when I add a feature. I tried perl and it handles the interesting code only with the utmost protest. Adding checksums and other interesting pieces is much easier if it only needs to be both coded in one language, and usually the C implementation is much easier than the perl. Plus C is fast :)
Have fun,
Eric
On Tue, 2003-01-14 at 08:19, Eric W. Biederman wrote:
After a long and tedious grind I am pleased to announce version 2.0 of mkelfImage. New features.
- One single binary
- Itanium support
- All of the code is in C.
- New and exciting easter eggs (err bugs can you find them before I do?...)
Available at: ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.0.tar.gz
rpms can be built with rpm -ta mkelfImage-2.0.tar.gz alien will make perfectly serviceable debs from those...
The decision to go with pure C is that it is both relatively portable, and it reduces maintenance when I add a feature. I tried perl and it handles the interesting code only with the utmost protest. Adding checksums and other interesting pieces is much easier if it only needs to be both coded in one language, and usually the C implementation is much easier than the perl. Plus C is fast :)
Eric, Something off topic, the elfImage made by mkelfImage 1.1x can not be recognized by 'objdump' but can be dumped by 'readelf'. Is there any reason for this ? Is this fixed by ver. 2.0 ?
ollie lho ollie@sis.com.tw writes:
Eric, Something off topic, the elfImage made by mkelfImage 1.1x can not be recognized by 'objdump' but can be dumped by 'readelf'. Is there any reason for this ?
Yes. This is a bug in some versions of objdump. On my current system this bug does not occur. It can be worked around by putting in a dummy symbol table, but this increases the size by a few bytes. Possibly a problem in an embedded situation.
Is this fixed by ver. 2.0 ?
No.
And my version objdump which does not show the problem is:
eric@maxwell:~$ objdump --version GNU objdump 2.13.90.0.10 20021010 Debian GNU/Linux Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.
Eric