Nwnsc compiler added to AUR

Neverwinter Nights 1 Promo
1

Howdy, all! I’ve added a package for the nwnsc compiler to the Arch User Repository. This allows Arch Linux users to easily install nwnsc as a package on their system.

Requirements

This package requires lib32-gcc-libs from the multilib repository. See the wiki for how to enable multilib.

Outdated requirements

Since nwnsc’s installation script relies on docker, you need to install the docker package, start its daemon, and ensure your user is added to the docker group:

# pacman -S docker
# systemctl start docker.service
# usermod -aG docker $USER

If you don’t want to relog for your groups to be updated, you can run:

$ exec sg docker newgrp $(id -gn)

Installation

You can install the package using the AUR helper of your choice:

$ yay -S nwnsc-git

Alternatively, you can install it manually:

$ git clone https://aur.archlinux.org/nwnsc-git.git
$ cd nwnsc-git
$ makepkg -si

I hope this is helpful!

Update: the package no longer requires docker to install.

1 Like
2

Cool! Why does it need docker?

3

It’s a build dependency. Why, I’m not sure, but that’s what the build script that is bundled with it uses. I get that memory error that you helped me with if I don’t use docker to build it, so it’s likely related to Arch’s configuration.

Getting rid of the docker dependency is next on my to-do list.

4

You can do that by not using the build script. The usual worked for me:

git clone https://gitlab.com/glorwinger/nwnsc
cd nwnsc
cmake .
make

Multilib is needed as the program targets 32-bit. It fails to compile for x86_64.

1 Like
5

On Arch, building it that way is successful but nwnsc aborts with an error when following include files when compiling scripts.

6

Ah, you meant it fails to compile a nss. Does it work without includes then? With latest git too? What’s your gcc version? Works for me with 5.5.0, with -i and without in 1.69 mode.

7

Ah, I misremembered. The error appears regardless of whether the script includes others or not. And yes, I am using the latest version. My gcc is 8.3.0.

Doing a little more research, it looks like the docker install script is building using Holy Build Box 32. I’m not sure whether this setup has some library that I don’t have installed locally. Any suggestions?

1 Like
8

That bug is because the code is doing something invalid/undefined. Because it is undefined, behavior can easily change between compiler/library versions. It just so happens that the version used with docker doesn’t manifest it, but the bug is still there and anything could expose it… Maybe now it only happens on Tuesdays?

We should fix the bug, or even just apply the stupid hack I gave you.

2 Likes
9

I’ve applied that hack and removed the docker dependency. valgrind shows some more errors that aren’t present in the docker build, but it doesn’t appear to stop the program, so I suppose it’s good enough for now.

10

Have you tried building it for 64 bit? Avoiding multilib could help. I’m getting overload/redefinition errors from gcc, but newer version may work.

11

I get those errors when trying to compile as 64-bit, too. Doesn’t look like a newer version of gcc helps.

12

Okay, I’ve got a solution kludge to make it compile for 64-bit :slight_smile: (not portable to 32-bit).

Diff for _NwnUtilLib/BufferParser.h 
108c108
< 			 unsigned long &FieldBits
---
> 			 long &FieldBits
287c287
< 			 unsigned long &FieldBits
---
> 			 long &FieldBits

I cannot guarantee this is correct in 100% of cases, but compiled test scripts are binary-identical when compared to 32-bit build.

The problem was that under x86_64 long and uint64_t are both 64-bit, which makes method declaration equal, and thus not-overloadable.

13

It compiles for me, but when I attempt to use it, I get the following:

WARNING: Failed to open .key archive '/home/squattingmonk/Games/00840/data/nwn_base.key': exception 'Header.FileVersion is not V1 (illegal KEY file)'.
14

Yeah, I get that too when using the -n switch. But try without it: extract nwscript.nss to the folder with binary and compile there. It should work (works for me). While obviously not ready for production, it may give an answer whether the free error happens without multilib too.

This is why using platform-dependent longs (or other built-in types) to read data of known fixed length is bad idea. In order for this program to work on both 32 and 64 bit systems one would at least need to heavily alter _NwnUtilLib/OsCompat.h make a smarter kludge or fix all NWN data-related longs in the library to (u)int32_ts.

PROTIP: How to find sizes of all built-in types w/o making any programs. 
$ echo | gcc -E -dM - | grep SIZEOF | sort
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_FLOAT128__ 16
#define __SIZEOF_FLOAT80__ 16
#define __SIZEOF_FLOAT__ 4
#define __SIZEOF_INT128__ 16
#define __SIZEOF_INT__ 4
#define __SIZEOF_LONG_DOUBLE__ 16
#define __SIZEOF_LONG_LONG__ 8
#define __SIZEOF_LONG__ 8
#define __SIZEOF_POINTER__ 8
#define __SIZEOF_PTRDIFF_T__ 8
#define __SIZEOF_SHORT__ 2
#define __SIZEOF_SIZE_T__ 8
#define __SIZEOF_WCHAR_T__ 4
#define __SIZEOF_WINT_T__ 4

Credits

1 Like