Building nsisbi on non-Windows

Has anyone on this forum managed to build nsisbi on macOS or Linux? I'm using the same SCons parameters that work for standard NSIS, but always run into this error:

/usr/local/opt/scons/bin/scons makensis STRIP=0 ZLIB_W32=~/Desktop/zlib128-dll SKIPUTILS=NSIS Menu

Last 15 lines from ~/Library/Logs/Homebrew/nsisbi/01.scons:

         ^~~~~~~~

         ftello

/usr/include/stdio.h:332:8: note: 'ftello' declared here

off_t    ftello(FILE * __stream);

         ^

Source/util.cpp:653:10: error: use of undeclared identifier 'fseeko64'; did you mean 'fseeko'?

  return fseeko64(fp, pos, filepos);

         ^~~~~~~~

         fseeko

/usr/include/stdio.h:331:6: note: 'fseeko' declared here

int      fseeko(FILE * __stream, off_t __offset, int __whence);

         ^

2 errors generated.

scons: *** [build/urelease/makensis/util.o] Error 1

scons: building terminated because of errors.

I've also tried specifying different TARGET_ARCH values and 64-bit versions of zlib, but to no avail.

I'm guessing this is related to 64-bit file sizes. Using 'fseeko' might work, depends on sizeof(off_t). There is usually a define you have to set at the top of the .cpp file before any #includes to trigger 64-bit support. You have to read about it in the documentation for your std c library and #ifdef in whatever code you need for your platform.

There should be plenty information about this, just google "fseek 64 yourplatform" etc.

Thanks for the hint, Anders. This looks promising:https://stackoverflow.com/a/4003512/1329116

Will give it a try on the weekend!

Building works fine when I add the following to Source/util.h:

#ifdef __APPLE__

#  define fseeko64 fseeko

#  define ftello64 ftello

#endif

The reason why I'm so interested in getting this to work is Homebrew, a popular package manager for macOS (also available for Linux). Now I have two options integrate this change:

1. patch util.h before building
2. hope that upstream adds this to util.h

Both work fine, but of course the second option feels cleaner. Any objects to add these four lines of code, JasonFriday13?

The main reason I have to use fseeko64() is to support installer sizes between 2GB and 4GB. off_t says it is defined as a signed type, so passing it anything over 2GB will cause an error.

You can try creating a 3GB installer and seeing if it errors out.

Originally Posted by JasonFriday13 View Post

The main reason I have to use fseeko64() is to support installer sizes between 2GB and 4GB

According to that Stack Overflow answer, Darwin file I/O is 64-bit by default since 2007. So for my (little) understanding aliasing *64 should suffice. Anyway, I wonder what you make of second answer, is this the better solution for this case?

You can try creating a 3GB installer and seeing if it errors out.

Creating a 10GB installer worked fine!

Yeah, external files work fine because makensis doesn't need to know the size to write the external file out, it just stores the size in the first header.

All in one installers between 2GB and 4GB might be a problem, because of the signed int overflow, which is why I asked you to try a 3GB installer and see if it runs ok.

fseeko64 might be gcc specific, I'm only using gcc on ubuntu for my testing.

http://www.gnu.org/software/libc/man...st-Macros.html tells you there are at least 3 configurations: _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS. Some make off_t/fseeko 64-bit and some add 64-bit specific functions and off64_t but at the end of the day you should be able to work with > 4GiB files on anything less than 20 years old probably.

Cool. In Platform.h, just define this before the includes, and see if that helps:

#ifndef _LARGEFILE64_SOURCE
#define _LARGEFILE64_SOURCE
#endif

I would rather have a separate interface for the 64 bit versions, and not have one replace the other.

Originally Posted by JasonFriday13 View Post

All in one installers between 2GB and 4GB might be a problem, because of the signed int overflow, which is why I asked you to try a 3GB installer and see if it runs ok.

3GB all-in-one installer works fine!

In Platform.h, just define this before the includes, and see if that helps

That throws the same error as in my initial post

Ok, so it is probably redirecting fseeko to fseeko64 behind the scenes, so I'll have to test this out (in source/util.h, after the includes):

#ifndef fseeko64
#define fseeko64 fseeko
#endif

#ifndef ftello64
#define ftello64 ftello
#endif

I would rather not use platform specific defines, unless the function names are different (like fseeki64 on windows).

Originally Posted by JasonFriday13 View Post

I would rather not use platform specific defines, unless the function names are different (like fseeki64 on windows).

This works fine. Thank you.

Will you add these changes in the next version of nsisbi? My Homebrew formula patches the file right now, but of course it would be nicer without it.

I'm not opposed to taking this upstream as well at some point but we don't need it currently. It we ever need it, it should probably be a helper function in util.h. I don't want to take it right now because I don't want to maintain code that is unused (by us), toolchain specific, and not part of the C standard.

The only 64-bit file stuff we currently use is the file size of redirected stdout on Windows (IIRC).

The patch will be in the next version, but I am going to wrap it into a #ifndef _WIN32 block.

It's interesting though, some setups redirect the call, and some keep them separate. If I recall correctly, the 64 bit calls are only for all-in-one installers between 2GB and 4GB.

I am considering adding another setting that allows splitting the data block into two parts, one for the exehead and one for the main install files. I'm thinking of using reservefile to add exehead specific files, the main reason is so that the installer .exe can become a downloadable stub, so that it downloads quick. Then it can be run with some downloader plugin that downloads the main datablock file. I will probably add a check for existing datablock files too, so that it only has to be downloaded once. Don't know when that will happen, I am quite busy at the moment.

[edit] Also, I'm ok with which ever way nsis goes. It's quite nice having a fork because it keeps the main nsis package tight and lean, I don't actually like bloated software much. [/edit]

Oh and I also wondered why my downloads of nsisbi have spiked up, the homebrew script fetches my source code 🙂.

Originally Posted by JasonFriday13 View Post

Oh and I also wondered why my downloads of nsisbi have spiked up, the homebrew script fetches my source code 🙂.

🙂

Originally Posted by Yathosho View Post

Building works fine when I add the following to Source/util.h:

#ifdef __APPLE__

#  define fseeko64 fseeko

#  define ftello64 ftello

#endif

The reason why I'm so interested in getting this to work is Homebrew, a popular package manager for macOS (also available for Linux). Now I have two options integrate this change:

1. patch util.h before building
2. hope that upstream adds this to util.h

Both work fine, but of course the second option feels cleaner. Any objects to add these four lines of code, JasonFriday13?

I'm close to finishing the next version of nsisbi, can I ask you to do a little testing for me please? I've added a new mode, and a handful of new instructions:

SetExOutFile has been renamed: OutFileMode auto|aio|data|stub
Stub mode turns the installer into a stub, which can run without the main .nsisbin file. And this allows an internet plugin to download the file, and then use that for the install.

StubFile, for adding files to the stub (otherwise identical to File)
ReserveStubFile, for reserving files in the stub (otherwise identical to ReserveFile)
VerifyExternalFile [path_to_nsisbin], used to verify and use the .nsisbin file.

These are documented in the help files too.

If you run into any issues, let me know 🙂 .

Diff (use NSIS 3.04 stable as the base): https://pastebin.com/iKK3KC7p

@Yathosho

You should not have to patch the source code for 3.04.1, 3.04.2, and 3.05.1. I've used _FILE_OFFSET_BITS == 64 to enable 64 bit file support, which means fseeko64 and ftello64 have been removed. 🙂

@JasonFriday13 Thanks for the update 👍