Hi, squashfs authors assume that an int is as wide as a pointer and mksquashfs breaks on all platforms where this isn't true.
Created attachment 33390 [details, diff] squashfs2.0-amd64.diff
Thomas: did you do that patch on your own ? Or is it tested patch from a different source ?
i wrote this patch myself. it works fine here. it basically takes away the int->ptr cast and uses the integer as offset to a base pointer, so it should be safe.
Honestly i don't like your patch. It's a ugly hack. Also the whole code of mksquashfs looks _very_ ugly. Casting unsigned int to pointers and back, using (unsigned int *) for the purpose of (void **). Thats not nearly 64bit clean.
after my patch applied gcc doesn't report any pointer to integer of different size casts any more. what would you consider a "clean" solution? (except for recoding the whole tool *sigh*) i did not want to modify the code, so that a long int is used instead of a int, so that a pointer would fit into it, because that would have caused larger changes, but is perhaps a cleaner solution. i would be willing to do this if you request it. using pointer->integer->pointer casts is not that evil in C if you do it right IMO. PS: sorry for bad english, vodka is evil ;)
Don't get me wrong, i appreciate your work, and it is probably an appropriate solution. I just got back, but i think i will apply the patch lateron.
Any reason this would be a amd64 bug and not an outright 64bit bug? Anybody run these changes by upstream? If not Thomas Weidner could you please do so. (thanks in advance)
Nope, no reason for amd64 only patch. Reassigning to maintainer.
I'm the author of mksquashfs. I've known about the pointer->int problem for some time (it was a piece of sloppy coding done in a hurry to implement a feature a user wanted). There is another 64 bit bug in the program. I didn't know that a long on 64 bit machines was 8 bytes long. This breaks the call to the zlib compress/uncompress routines. I'll release a new version with both bug fixes.
in which way? i used images created with "my" mksquashfs without problems
squashfs2.0-r2.tar.gz released now. Please see if it works and remind me in a week or two if I haven't commited a version bump.
tested it with a few kb and 1.1 GB squashfs filesystem. works fine here.
squashfs-tools-2.0_p2.ebuild added to correspond to squashfs2.0-r2.tar.gz Arch tests - please do your best. src_test routine has been added for arch testing. The src_test routine that requires a squashfs in the kernel (or module) and FEATURES=-userpriv (needed to mount filesystems) Phillip I added you here so you could see what architectures is does/doesn't work on. ------------------- For 64 bit arch maintainers - suggest removing pre-alpha *64 keywords - The text below if from a file in the latest version. Information for amd64 users --------------------------- All previous releases of Squashfs (2.0-alpha and older) generate incorrect filesystems on amd64 machines. These filesystems work correctly on amd64 machines, but cannot be mounted on non-amd64 machines. Likewise, filesystems generated on non amd64 machines could not be mounted on amd64 machines. This bug was caused by the different size of the "time_t" definition used in SquashFS filesystem structures. This bug is now fixed in this release. However, all amd64 filesystems generated by previous releases will not be mountable on amd64 machines with this release. If you have pre-existing amd64 generated filesystems, it is important that you recreate the filesystem. This can be performed by mounting the filesystem using a kernel with the original patch (i.e. a 2.0-alpha or older patch) and running the SquashFS 2.0 (i.e. this release) mksquashfs tool to create a new SquashFS filesystem.
sparc stable, looks tasty.
a bunch of arches have this stable now
also stable on ppc64 since some time