[PC] LGP inserter/extractor/repacker & library - ulgp (1.2)

  • Thread starter Thread starter luksy
  • Start date Start date
Status
Not open for further replies.
That's one way, I might just have to add support for standard globbing as this is obviously too complicated. As for the switches, they are based on the tar command. Also I'm keeping the libs separate as my apps will all be using them anyway, I'll make an installer or something.

Oh and I'll redo the GUI soon too.
 
|
Click to expand...
that straight up line key on keyboard i can't press because it's located underneath Esc key and it's got 3 symbols in one :o i press it this comes ` or with Shift then this ¬ so how on earth can i make it do that straight line button in that same key? XD never mind i give up, thanks again :D
 
yeah the best way to do it is to add  a normal encoder option.  Use some other flag.  Most people who are encoding are encoding from a folder anyway...  i dont see any real need to specify 1 or 2 files to be appended.  In nearly every case, having files inside the target folder is simple and works (and you can still append 1 or 2 files this way).
 
Having trouble compiling the source in MinGW, i have installed MinGW GCC 4.8.1 and Boost 1.54.0 but i keep getting errors trying to compile main.cpp
Code: [Select]
Code: 
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x45): undefined reference to `boost::filesystem::path::parent_path() const'C:\Temp\cc76I0PB.o:main.cpp:(.text+0x4c0): undefined reference to `lgp::Archive::Archive()'C:\Temp\cc76I0PB.o:main.cpp:(.text+0x4f2): undefined reference to `lgp::Archive::addLgp(std::string const&)'C:\Temp\cc76I0PB.o:main.cpp:(.text+0x6bf): undefined reference to `lgp::Archive::addFile(std::string const&)'C:\Temp\cc76I0PB.o:main.cpp:(.text+0x79e): undefined reference to `lgp::Archive::write(std::string const&) const'C:\Temp\cc76I0PB.o:main.cpp:(.text+0xed0): undefined reference to `boost::system::generic_category()'C:\Temp\cc76I0PB.o:main.cpp:(.text+0xedc): undefined reference to `boost::system::generic_category()'C:\Temp\cc76I0PB.o:main.cpp:(.text+0xee8): undefined reference to `boost::system::system_category()'c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Temp\cc76I0PB.o: bad reloc address 0x0in section `.data'collect2.exe: error: ld returned 1 exit status
any help you can give would be nice, thanks
 
If boost was compiled with mingw you need to link the filesystem and system dll's when compiling (just add them directly like any other object file), if not you'll need to link to the import libs instead.
 
I am kind of a newbie when it comes to compiling (usually i just follow directions and it works), so i don't fully understand what you mean but i have tried Compiling boost myself and using a precompiled version from http://nuwen.net/mingw.html and both fail to compile, i did try adding the libs to the same folder as the ULGP source but still got errors, guess this may be out of my league.
Also another small question but why is boost used on this version of ULGP but not on previous ?
 
It just occurred to me you're not linking the lgp object file either, anyway try downloading my libs archive and copy it to the same dir as the source, and run this

g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll
 
OK i have now put the source and the libs into the same folder, then typed "g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll" and it did this

EDIT- Sorry that was my fault, i corrupted my MinGW installation, reinstalled and now i get
Code: [Select]
Code: 
C:\MinGW\ulgp>g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dllc:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386 architecture of input file `libboost_filesystem.dll' is incompatible with i386:x86-64 outputc:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386 architecture of input file `libboost_system.dll' is incompatible with i386:x86-64 outputC:\Users\Kram2\AppData\Local\Temp\cccsYswN.o:main.cpp:(.text+0x27): undefined reference to `boost::filesystem::path::codecvt()'C:\Users\Kram2\AppData\Local\Temp\cccsYswN.o:main.cpp:(.text+0x48): undefined reference to `boost::filesystem::path_traits::convert(char const*, char const*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&,std::codecvt<wchar_t, char, int> const&)'c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Kram2\AppData\Local\Temp\cccsYswN.o: bad reloc address 0x0in section `.data'collect2.exe: error: ld returned 1 exit status
 
Last edited:
Ah this might be to do with a std::to_string conflict, maybe the mingw distro you downloaded includes those functions because standard mingw hasn't got around to it yet, adl might be causing my own to_string function to conflict with the std:: versions, I'll change the name.

edit: I've updated the source in the lgp.7z archive, hopefully the conflict is gone now (haven't tested!).

edit2: Ah ok saw the updated, basically you're trying to link my boost libs which are 32bit using your 64bit mingw, that won't work, you'll either have to fix your boost lib issue or just use the standard mingw.

Also I'm using boost filesystem because 1. I've become a bit of a portability nut, 2. boost::filesystem is in C++ TR2 and will probably be part of the standard library at some point, and 3. the winapi functions are a pain in the ass!
 
Last edited:
I'm still getting the same errors, i'm guessing its just me, i will just give up on building the source for now, thanks anyway :)
 
It should work with plain mingw and the boost dlls I built

http://sourceforge.net/projects/mingw/files/latest/download

You need to make sure you uninstall the other mingw because it's probably modified your PATH env. variable, IIRC normal mingw won't though so you'll have to add it manually.


As for making changes to the interface, the reason things are the way they are now means I don't need to second guess what the user is attempting to do, which would actually be relatively easy if it weren't for magic.lgp and the insane lgp path handling.

It doesn't help that the windows dir function is schizophrenic: dir /b gives a raw dump of local filenames, dir /s gives a recursive dump using relative paths but with full dir info.  Use them together and for some reason the paths are now absolute, which isn't a problem for any other file except magic.lgp.

Making changes to the interface to fix these issues will result in either a loss of flexibility, or require even more options which in a way complicates things further, most of the complexity of the syntax can be fixed with batch files anyway.

Come to think of it this can be resolved mostly by allowing dirs to be specified in the file list, I'll update it.

What does everyone think?

Ok with a few tiny changes things are a lot easier for non-magic.lgp archives and it still remains as flexible as before.
Entire folders can be specified in the file list, so if you want to create an archive from scratch from a single folder, it's enough to say

ulgp -c foo.lgp thefolder

Note that this WON'T work for magic.lgp because paths are important, magic.lgp would have to be

dir /b thefolder | ulgp -c foo.lgp -eC thefolder

I'll upload the changes later.

Actually this will cause problems if you need to overwrite...sigh. I'll think of something.

Ok got it, was actually fairly straightforward and should make all of us happy.
 
Last edited:
Thanks luksy i finally got it working, installed the latest version of MinGW from that link (i was downloading from their sourceforge site and it was downloading a old installer) and removed all my old environment paths and started fresh, in the end the final command i used to get it working was
g++ -I C:\MinGW\ulgp\boost_1_54_0 -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll
Thanks again.
 
Cool, I'll have the updated version uploaded soon.

Ok one for testing

https://dl.dropboxusercontent.com/u/3227870/ulgp_v1.1.7z

Basically the only change is that if you do not specify any files when creating or appending, all files are read, so these should now all work as expected:

dump all:
ulgp -x archive.lgp -C targetFolder

create lgp from scratch using all files / folders in targetFolder
ulgp -c archive.lgp -C targetFolder

overwrite all files
ulgp -r archive.lgp -C targetFolder
 
Last edited:
Seems to work a charm. After kranmer places it all together and after upx, it comes out at 225KB

1 small issue though.  When using wrong tag (like -e instead of -r), the app hangs.  But that's small potato.

Good job!
 
The app isn't hanging, it's waiting for input on the command line if you use -e.

Also I can appreciate wanting to plonk everything into one file, but that defeats the idea of keeping the code separate and the file size to a minimum, you end up distributing multiple copies of the libs with every app. Not that I have other apps planned but you never know. And I've kind of gone off upx too, compression is understandable for distribution (that's where 7zip comes in) but not necessary for the actual executable with today's storage spaces.
 
For me it just makes things nice and neat to have it in 1 package (especially with installer) .  After upx and all the files in the exe, it comes out as around 220 KB not bad!

I know why you want it separate too tho.  8-)

Obviously if I had like 5 of your programs I had to distribute with an installer, it would be pointless combining all the files.  I just think a standalone command line tool should be 1 exe.   It isn't any biggie anyway, you release the source so people can use it.
 
Last edited:
Ok here's what are ideally the final versions of the commandline and GUI app

http://goo.gl/WxHoSa

(the google shorterner is just to let me know how many times it's been clicked).

This archive has all the libs and source included, I tested it briefly but would appreciate anyone who can chip in (Dan...:D)
 
Last edited:
Thanks for the new version Luksy, having problems making a LGP with sub folders using the GUI or command line, i tried using
dir /b thefolder | ulgp -c foo.lgp -eC thefolder
as you posted that previously but it still doesn't do sub folders,
Dan has told me that -r works with sub folders but -c doesn't.
But anyway other then sub folders everything else seems to be working great :) Thanks
 
Status
Not open for further replies.
Back
Top