Bernhard R. Link wrote:
There might be ways to help libraries to still link against libarchive without having to change their off_t to 64 bit, but using off64_t in those cases.
Actually, I believe I've laid the groundwork to make the 64-bit/32-bit issue completely transparent to software using libarchive. It requires someone knowledgable about this area of Linux to help me fill in the few remaining pieces, but should not require any deep knowledge of libarchive internals. The most important piece is to create three versions of archive_entry_stat() and archive_entry_copy_stat() (which copy data between a platform-native struct stat and libarchive's internal storage): * archive_entry_stat32 and archive_entry_copy_stat32, which deal with "struct stat32" * Similar archive_entry_stat64 and archive_entry_copy_stat64 * archive_entry_stat() and archive_entry_copy_stat() would be defined twice: In code as synonyms for the 64-bit versions (to preserve ABI compat for programs using the shared libraries) and as macros that map to 32-bit or 64-bit versions depending on the off_t size being used by the program. There are a couple of entry points defined in archive.h that use off_t directly, but those are rarely used and so are less critical. Once the above is working, similar techniques should apply to them. Getting all of the configuration right so this builds correctly on platforms that don't have two different off_t/struct stat definitions is probably the trickiest part. This is a low priority for me right now, though I do believe that I've factored the internals well enough to make this a feasible project for someone who knows nothing about libarchive. If anyone is interested, let me know. Tim Kientzle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
