libhl - NemPosted: May 23rd, 2005 - 6:30:02 pm

SavannahLion of HLPD has ported my HLLib library to Linux. The port has been dubbed libhl and contains a HLExtract clone Slatch.

Modified: Jun 17th, 2006 - 4:30:24 pm[ 48454 Views ]

1. Da_FileServerPosted: Jun 17th, 2006 - 4:23:46 pm
The link appears to be dead; the website says it's still there... but it redirects to a page that doesn't exist.


2. panziPosted: May 26th, 2011 - 7:19:16 pm
I wrote a small cmake build system for the Linux port (who knows, maybe it works also under other operating systems):

mkdir HLLib-build
cd HLLib-build
make -j2 && sudo make install
sudo ldconfig # <- don't know if this is really needed
mkdir HLExtract-build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../HLExtract
make -j2 && sudo make install

If you install HLLib somewhere else than /usr also pass -DCMAKE_MODULE_PATH=$PREFIX/cmake/modules to the second cmake call.

This installs following files into your $CMAKE_INSTALL_PATH:

Note: There are many warnings when compiling HLLib. Some of them seem to me potentially serious (using uninitialized variables, crazy casts and such). Maybe someone should take a look at that. Maybe they aren't really serious.

3. acidkingModified: Aug 16th, 2011 - 8:06:23 am
Thanks Panzi.

When I ran 'make -j2 && sudo make install' I got the error:

CMake Error at cmake_install.cmake:56 (FILE):
file INSTALL cannot find "/Users/acidking/HLLib/../lib/HLLib.h

So I tried to edit 'HLLib-build/cmake_install.cmake', to correct the path:


It worked, and then when I ran 'cmake -DCMAKE_INSTALL_PREFIX=/usr ../HLExtract', I got this error:

CMake Error: The source "/Users/acidking/HLExtract/CMakeLists.txt" does not match the source "/Users/acidking/HLLib/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.

What could be the problem?

4. edman747Posted: Sep 11th, 2012 - 6:54:36 pm
We are currently using hlextract to get bsp's from both the
half-life.gcf and the opposing force.gcf
hlextract is called from two batch files in the svencoop folder

We released a beta Linux server for svencoop 4.6
Would like to write a shell script that will help server operators install HLSP and OpFor support in Linux

HLExtract using HLLib v2.3.0
Is there a newer version?
Is there a Linux version of HLExtract?

Thank You,

5. Ravu al HemioPosted: May 7th, 2013 - 2:13:11 pm
I've been working on an improved Linux version of HLLib and HLExtract; it is available on my github page. I'll try to keep it in sync with the upstream version of HLLib; if I don't, open an issue there.

6. panziModified: Mar 14th, 2014 - 5:02:53 am

I made a git mirror here and started fixing compile errors you get when you compile with -Wall -Wextra -pedantic -Werror:

Summary of my fixes so far:
lpOffsets[i] cannot be -1, did you want to compare to the maximum value (i.e. (hlULongLong)-1)?:

uiLength cannot be less than 0:

iMode might be used uninitialized:

there is no long long type in standard C++ (I changed it to int64_t):

'SGAHeader' was not declared in this scope:
Should it be CSGASpecializedDirectory::SGAHeader or TSGAHeader?

standard C++ can't cast between data and function pointers, but there is a trick how to do it anyway:

Also I added "default: break;" to every switch statement that does not enumerate all enum values (or else it won't compile with the given flags).

The flags also disallow unused parameters. I explicitly silenced those by adding "(void)param;" (creates no extra binary code).

The error about SGAHeader is a bit concerning and kinda stops me from fixing more errors. What was meant here?

7. panziModified: Mar 15th, 2014 - 4:51:34 am
One more thing:

dereferencing type-punned pointer will break strict-aliasing rules:

Also I think it's not endian-safe. So I do this instead:


#define HL_FOURCC_TO_UINT(FOURCC) (hlUInt)(FOURCC[0] | FOURCC[1] << 8 | FOURCC[2] << 16 | FOURCC[3] << 24)

const hlChar *lpFourCC = this->pHeader->lpLumps[uiID].lpFourCC;
hlAttributeSetUnsignedInteger(&Attribute, this->lpItemAttributeNames[eAttribute], HL_FOURCC_TO_UINT(lpFourCC), hlTrue);

8. panziPosted: Mar 15th, 2014 - 6:08:02 pm
Hmm, I think I'm going to change all usages of strcpy, strcat, strncpy and strncat to strlcpy and strlcat (copying the BSD implementation of those and compiling it if the functions aren't available). This should make the code simpler (where strncpy/strncat was used before) and more safe (in any case). These functions ensure nil termination(!) and the size parameter is the size of the buffer (including nil), not the number of characters to copy.

I also do a similar thing for sprintf => snprintf.

9. panziModified: Mar 15th, 2014 - 6:51:07 pm
Also I see you use hlUInt (which is 32bit, even on a 64bit system) at a lot of places even when you handle values that might need 64bits. E.g. st_size as used in HLLib::GetFileSize is actually a signed 64bit value on 64bit Linux and also on 32bit Linux if you compile using -D_FILE_OFFSET_BITS=64 (which you should).

I could change it to some hlSSize type that has the appropriate size on all platforms (hlULong would not be fine on 32bit Linux plus -D_FILE_OFFSET_BITS=64). Shall I? It would break binary (and I guess also source) compatibility with existing Linux code using HLLib (I wouldn't change it for Windows because I can't test it under Windows).

10. panziModified: Mar 15th, 2014 - 10:31:24 pm
Is it correct, that when a file has no parent, then it's path won't get lpRootPath prepended? See:

11. panziPosted: Mar 16th, 2014 - 4:15:23 am
I added these static methods with which one can open any supported package where the CPackage subtype is automatically determined by the data:


static CPackage *CPackage::AutoOpen(Streams::IStream &Stream, hlUInt uiMode);
static CPackage *CPackage::AutoOpen(Mapping::CMapping &Mapping, hlUInt uiMode);
static CPackage *CPackage::AutoOpen(const hlChar *lpFileName, hlUInt uiMode);
static CPackage *CPackage::AutoOpen(hlVoid *lpData, hlUInt uiBufferSize, hlUInt uiMode);
static CPackage *CPackage::AutoOpen(hlVoid *pUserData, hlUInt uiMode);

Don't know about the name.


12. panziPosted: Mar 17th, 2014 - 4:08:09 am
Ah I also added these static methods:


static CPackage *CPackage::Open(Streams::IStream &Stream, hlUInt uiMode, HLPackageType ePackageType);
static CPackage *CPackage::Open(Mapping::CMapping &Mapping, hlUInt uiMode, HLPackageType ePackageType);
static CPackage *CPackage::Open(const hlChar *lpFileName, hlUInt uiMode, HLPackageType ePackageType);
static CPackage *CPackage::Open(hlVoid *lpData, hlUInt uiBufferSize, hlUInt uiMode, HLPackageType ePackageType);
static CPackage *CPackage::Open(hlVoid *pUserData, hlUInt uiMode, HLPackageType ePackageType);

I use one of them in hlfs, a fuse file system that uses HLLib. :)

13. SnowiePosted: Mar 30th, 2014 - 1:12:09 pm
Hi all,

Tried to build HLLib on my Ubuntu box, but gcc or g++ compiler thingy or whatever... (just to give you an idea of how well I understand C and derivatives) complains about one of the files> SGAFile.h

So I run the following from /opt/HLLibTools where extracted and I get:


$ sudo make -C HLLib Makefile install
make: Entering directory `/opt/HLLibTools/HLLib'
make: Nothing to be done for `Makefile'.
g++ -c -O2 -g -fpic -funroll-loops -fvisibility=hidden -o Wrapper.o Wrapper.cpp
In file included from Packages.h:17:0,
from Wrapper.cpp:16:
SGAFile.h:279:3: error: a class-key must be used when declaring a friend
SGAFile.h:279:3: error: friend declaration does not name a class or function
SGAFile.h:280:3: error: a class-key must be used when declaring a friend
SGAFile.h:280:3: error: friend declaration does not name a class or function
SGAFile.h:281:3: error: a class-key must be used when declaring a friend
SGAFile.h:281:3: error: friend declaration does not name a class or function
SGAFile.h:282:3: error: a class-key must be used when declaring a friend
SGAFile.h:282:3: error: friend declaration does not name a class or function
make: *** [Wrapper.o] Error 1
make: Leaving directory `/opt/HLLibTools/HLLib'

Some reading suggests that while this will get by most C++ compilers, GCC or G++ or whatever will not allow it and requires class to be declared, but if I add the line
friend class CSGADirectory*
for each line, I get even more and more errors complaining about the lines above it.

Checked some other *File.h files for reference but none seem to have any friends ;) pun!

I'm probably doing something wrong, but if someone could take a look I would much appreciate it. Have included the culprits here:


typedef CSGADirectory<SGAHeader4, SGADirectoryHeader4, SGASection4, SGAFolder4, SGAFile4> CSGADirectory4;
typedef CSGADirectory<SGAHeader4, SGADirectoryHeader5, SGASection5, SGAFolder5, SGAFile4> CSGADirectory5;
typedef CSGADirectory<SGAHeader6, SGADirectoryHeader5, SGASection5, SGAFolder5, SGAFile6> CSGADirectory6;
typedef CSGADirectory<SGAHeader6, SGADirectoryHeader7, SGASection5, SGAFolder5, SGAFile7> CSGADirectory7;

friend CSGADirectory4;
friend CSGADirectory5;
friend CSGADirectory6;
friend CSGADirectory7;

cheers guys, I'm of to bed.

14. panziModified: Apr 23rd, 2014 - 9:03:28 pm
@Snowie I had the same problem. Seems like some standard strictness. I simply pasted the type to which the typedef refers into the friend declarations. This and more changes you can find here:
My version compiles with very strict compiler flags without warnings (last time I checked). I hoped my changes would be merged some day, but I didn't get an answer.

You must be logged in to post a comment.
New users can register here.
Nem's Tools v2.0 © 2006 Ryan Gregg.
Execution time: 0.032232s; Queries: 17.
dishes served.
Powered by The Wavelength.

Valid XHTML 1.0 Transitional Valid CSS