Results 1 to 12 of 12

Thread: packARC v0.7RC11 GPL release (and more)

  1. #1
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts

    Cool packARC v0.7RC11 GPL release (and more)

    Alright, this is my "I'm not dead" thread. Sorry for the lack of updates to everyone waiting. I've finally gotten around to revise some of my source codes, so here are my newest releases.


    packARC v0.7RC11 (GPL)
    I still don't consider this a proper release version because there are some yet unexplained bugs on low memory Linux based systems. Also, handling of very big input files (> 2GB) is still disabled by default and can be unlocked via source code changes. Always verify your compressed files and you should be good!

    This is new since the last release version (packARC v0.7RC6):

    • support for total archive size over 2GB
    • drag and drop support
    • handling of directories
    • backwards compatibility with all (to my knowledge) older versions
    • updated packJPG, packPNM and packMP3 libraries
    • ... and, of course open source under the GPL!

    Also note that this includes the most recent packJPG, packMP3, packPNM and packARI sources, which can therefore also be used under the GPL v3 (ie. everything besides packMP3 even under the LGPL). For more info, consult the included "readme.txt" file.

    Keep in mind that the concept for this is to be a media archiver for MP3/JPG rather than being a truly universal archiver. It can perfectly handle the occasional TXT/PDF/DOC/other file, but it is not intended to be used for large files such as ISOs. Don't expect any wonders for packARI - it is, after all, just an arithmetic encoder with an nth order Markov model. There are decent results for text files and many others, though.

    If you should stumble over a bug or do some improvements and / or additions, please let me know!

    packPNM v1.6a
    This includes experimental Radiance HDR (.HDR) support now. You have to use the "-p" command line switch and reconstructed files won't be bytewise the same as the original. Also, if you haven't noticed the previous version: full BMP support (alongside PPM, PGM and PBM) is included as well.

    packJPG v2.5h
    Just some small bug fixes, but this shows that I haven't given up on the project yet.

    unpackPJG v2.5h (BSD)
    This really is just a BSD rerelease of packJPG with all encoding functionality stripped. I did this on request, and perhaps some of you might have some use for this. At the very least it will allow .PJG decompression support in closed source projects.

    packMP3 v1.0d
    Nothing new, but for anyone who hasn't noticed yet: This has also been open source under the GPL for some time.


    Contributions / Derivatives by other authors
    ----------------------------------------------

    wxpackJPG by Roman Hiestand
    GUI for packJPG. Includes a modified, multithreading compatible packJPG library. A lot faster and more comfortable to use than "vanilla" packJPG.

    packJPG options / packMP3 options by Michael Lee
    GUIs for packJPG and packMP3 coded by Michael Lee.

    Java Wrapper for packJPG v2.5+
    This is released under the LGPL by the original author and might help you use packJPG in Java. It's used with a library called BridJ in combination with JNAerator to create the bindings. Included in the rar is the code that calls the packJPG native code as well as the .jnaerator file that can be used to create a jar containing the packJPG native code.
    Last edited by packDEV; 7th December 2013 at 22:14.

  2. Thanks (6):

    binarysoup (16th December 2013),JNZ (8th December 2013),load (8th December 2013),Nania Francesco (7th December 2013),samsat1024 (9th December 2013),Stephan Busch (8th December 2013)

  3. #2
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    Thanks for the new release, I did come across a problem when building packARC (the individual packers compiled and ran fine):

    I built the 'packANYlib.a' and 'packANYlib_small.a' libraries (with one small renaming fix, which was that it couldn't find 'packMP3lib.h' as it was named 'packmp3lib.h', and on *nix upper/lower-case are different names).

    I then built the sfxstub and finally packARC, everything compiled and linked fine, however when I execute the resulting packARC binary I only get a 'incorrect usage of SFX executable!' message.

    I'm on Arch Linux 64-bit

  4. #3
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Quote Originally Posted by binarysoup View Post
    Thanks for the new release, I did come across a problem when building packARC (the individual packers compiled and ran fine):

    I built the 'packANYlib.a' and 'packANYlib_small.a' libraries (with one small renaming fix, which was that it couldn't find 'packMP3lib.h' as it was named 'packmp3lib.h', and on *nix upper/lower-case are different names).

    I then built the sfxstub and finally packARC, everything compiled and linked fine, however when I execute the resulting packARC binary I only get a 'incorrect usage of SFX executable!' message.

    I'm on Arch Linux 64-bit
    Thanks for reporting this bug - I will check and get back to you later.

  5. #4
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 796 Times in 488 Posts
    Tested on LTCB. http://mattmahoney.net/dc/text.html#3619

    Edit: also tested on Silesia corpus: http://mattmahoney.net/dc/silesia.html

    Decompression verified OK on all files. On the 10GB benchmark ( http://mattmahoney.net/dc/10gb.html ) system 4 (Ubuntu/wine), packARC crashed after compressing for about 3 hours with the following message:

    processing file wine: Unhandled page fault on read access to 0x6d2f776b at address 0x43abd8 (thread 0009), starting debugger...

    It left files 10gb.a.tmp (81 bytes) and 10gb.tmp (2415540059 bytes). The command was:

    time packarc.exe a -np 10gb.pja 10gb
    Last edited by Matt Mahoney; 11th December 2013 at 03:28.

  6. #5
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Quote Originally Posted by Matt Mahoney View Post
    Tested on LTCB. http://mattmahoney.net/dc/text.html#3619

    Edit: also tested on Silesia corpus: http://mattmahoney.net/dc/silesia.html

    Decompression verified OK on all files. On the 10GB benchmark ( http://mattmahoney.net/dc/10gb.html ) system 4 (Ubuntu/wine), packARC crashed after compressing for about 3 hours with the following message:

    processing file wine: Unhandled page fault on read access to 0x6d2f776b at address 0x43abd8 (thread 0009), starting debugger...

    It left files 10gb.a.tmp (81 bytes) and 10gb.tmp (2415540059 bytes). The command was:

    time packarc.exe a -np 10gb.pja 10gb
    Thanks Matt! I'll look after this, too.

  7. #6
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Quote Originally Posted by binarysoup View Post
    I then built the sfxstub and finally packARC, everything compiled and linked fine, however when I execute the resulting packARC binary I only get a 'incorrect usage of SFX executable!' message.
    Alright, I adopted your naming fix (no new public release yet) and checked for that error message. This error message can only turn up when compiling with "SFX_STUB" defined ie. -DSFX_STUB in gcc compile options. This should also only be defined when actually compiling the SFX stub. So, you possibly used the wrong Makefile to compile the packARC main executable. Could you check this and give me some feedback?

  8. #7
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    Quote Originally Posted by packDEV View Post
    Could you check this and give me some feedback?
    Sure thing, I should have written a better explanation to begin with.

    First off I compiled the packANYlib.a and the packANYlib_small.a (the latter is for inclusion into the sfx stub I suppose) by using 'Makefile_lib_Linux' and 'Makefile_lib_Os_Linux' respectively.

    Then I copied the packANY*.a libs into the packArc directory and first built the sfx stub using 'Makefile_sfx_stub.linux' resulting in a 'sfxstub' file and finally I used the 'Makefile.Linux' to build the final packArc executable, everything compiles and links fine, but when I run the packArc executable I get the 'incorrect usage of SFX executable!' error.

    I hope this sheds some light as to where I went wrong, again the indivual packers all build and execute fine, it's just packArc which has a problem with the sfx stub.

    Again thanks for all these excellent packers!

  9. #8
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Quote Originally Posted by binarysoup View Post
    I hope this sheds some light as to where I went wrong, again the indivual packers all build and execute fine, it's just packArc which has a problem with the sfx stub.
    Alright, some more ideas and one possible insight. Do you mean that this problem is with SFX compressed files (not with packARC itself)? Otherwise this really shouldn't happen, as that error message would not even be accresible then. The error message is generated in frontend.cpp, at this point:
    Code:
        #if !defined(SFX_STUB)
        // name of this application (for help)
        my_name = clone_string( (char*) appname );
        #else
        // name of this application (for help), archive
        my_name = create_filename( get_filename( (*argv) ), NULL );
        archive = create_filename( (*argv), "exe" );
        if ( !file_exists( archive ) ) { // safety check
            fprintf( MSGOUT, "incorrect usage of SFX executable!" );
            return 0;
        }
        #endif
    The error message is shown if the archive (which is the same as the decoder in the case of SFX) doesn't have the .exe extension. And, yes, I only now notice that executable files in Linux are not called .exe but have an empty extension instead. Duh. I have to see if I can find a better solution.

    binarysoup, could you test decoding the compressed files using packARC (this will work for SFX as well!) instead of actually using SFX functionality? You may also try changing that part to this:
    Code:
        #if !defined(SFX_STUB)
        // name of this application (for help)
        my_name = clone_string( (char*) appname );
        #else
        // name of this application (for help), archive
        my_name = create_filename( get_filename( (*argv) ), NULL );
        archive = clone_string( (char*) my_name );
        #endif
    Last edited by packDEV; 13th December 2013 at 21:43.

  10. Thanks:

    binarysoup (16th December 2013)

  11. #9
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    Sorry for late reply, had a very busy weekend!

    Quote Originally Posted by packDEV View Post
    Alright, some more ideas and one possible insight. Do you mean that this problem is with SFX compressed files (not with packARC itself)? Otherwise this really shouldn't happen, as that error message would not even be accresible then.
    No it's actually directly when I run the compiled and linked packArc executable (with or without arguments) that I get this error message, the exact message is as follows:

    Code:
    --> packARC SFX Extractor v0.7RC11 (12/07/2013) by Matthias Stirner / Se <--
    --> packARC library v0.7RC11 (12/07/2013) by Matthias Stirner / Se <--
    --> contains: packJPG v2.5h, packMP3 v1.0d, packPNM v1.6a, packARI v0.6d <--
    Copyright 2006-2013 HTW Aalen University & Matthias Stirner
    All rights reserved
    
    incorrect usage of SFX executable!
    So it shows some program information and then encounters some problems with the sfx stub from what I gather.

    I tried to compile packArc (make -f Makefile.linux) without first building the sfx stub, but then I got a compile error in pja_archiver.cpp of it not being able to find 'sfxstub.h'.

    Maybe I'm doing something wrong when building the sfx stub, but everything compiles and links fine using the provided makefiles so I don't know what the problem could be.

  12. #10
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Here's a batch script for compilation in Linux:
    Code:
    #!/bin/sh
    #
    # 12-06-17  Se
    
    cd ./packANY/packANYlib
    make -f Makefile_lib_Linux
    make -f Makefile_lib_Linux clean
    make -f Makefile_lib_Os_Linux
    make -f Makefile_lib_Os_Linux clean
    
    cd ../../packARC
    cp ../packANY/packANYlib/packANYlib*.a ./
    
    make -f Makefile_sfx_stub.linux
    make -f Makefile_sfx_stub.linux clean
    upx --best --lzma sfxstub
    
    gcc -o sfxstub2h sfxstub2h.c
    ./sfxstub2h
    make -f Makefile.linux
    make -f Makefile.linux clean
    upx --best --lzma packarc
    
    rm sfxstub.h sfxstub sfxstub2h frontend.o helpers.o pja_archiver.o packANYlib.a packANYlib_small.a
    
    cp ./packARC/packARC.exe ../
    cd ..
    Although it should, no guarantees that it will work for you. Could someone try and give me some feedback?
    Attached Files Attached Files

  13. Thanks:

    binarysoup (11th January 2014)

  14. #11
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    Nice, I got it to work. Well, the script didn't (probably just because of me not having upx installed), but by looking at it I directly saw what I didn't do in my previous attempt, namely the following:

    gcc -o sfxstub2h sfxstub2h.c ./sfxstub2h

    I thought the sfxstub file generated by 'Makefile_sfx_stub.linux' was good to go, and just went ahead and built the final executable using Makefile.Linux .

    Anyway, both .pja and .exe archives were created and extracted correctly, although it's a small nuisance that the stub needs the .exe suffix in order to work as Wine associates with .exe files

    Again huge thanks for this excellent archiver and for helping me out in getting it to compile!

  15. Thanks:

    packDEV (11th January 2014)

  16. #12
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 44 Times in 9 Posts
    Thanks for testing! I'll see what I can do about the .exe extension in the next version. As for UPX: that's mainly because I don't want the SFX stub to inflate compressed archives. It's not actually needed, of course.

Similar Threads

  1. packARC v0.7RC6 (Release Candidate)
    By packDEV in forum Data Compression
    Replies: 14
    Last Post: 7th December 2013, 19:06
  2. diz.py release
    By Roger Flores in forum Data Compression
    Replies: 41
    Last Post: 11th February 2013, 08:49
  3. packMP3 v1.0c release
    By packDEV in forum Data Compression
    Replies: 11
    Last Post: 11th October 2012, 17:48
  4. ZPAQ pre-release
    By Matt Mahoney in forum Data Compression
    Replies: 54
    Last Post: 23rd March 2009, 02:17
  5. quad 1.07BETA2 - pre-release of 1.08 available
    By encode in forum Forum Archive
    Replies: 4
    Last Post: 11th March 2007, 22:59

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •