C++ build errors

[Timothy-Anders0n]

Upon trying to build the c++ standalone on linux, I came across the following error:

RNifti-1.5.1/standalone$ make all
cc -I. -DNDEBUG -DHAVE_ZLIB  -c -o niftilib/nifti1_io.o niftilib/nifti1_io.c
niftilib/nifti1_io.c:1:1: error: expected identifier or ‘(’ before ‘.’ token
    1 | ../../src/niftilib/nifti1_io.c
      | ^
make: *** [<builtin>: niftilib/nifti1_io.o] Error 1

if I change the file niftilib/nifti1_io.c's faulty line (also, its only line) into #include "../../src/niftilib/nifti1_io.c, and I do the same for the niftilib/nifti1_io.h file (#include "../../inst/include/niftilib/nifti1_io.h") and the file niftilib/nifti1.h (#include "../../inst/include/niftilib/nifti1.h") then I get the following error:

RNifti-1.5.1/standalone$ make all
In file included from ./niftilib/nifti1_io.h:1,
                 from niftilib/../../src/niftilib/nifti1_io.c:3,
                 from niftilib/nifti1_io.c:1:
./niftilib/../../inst/include/niftilib/nifti1_io.h:24:10: fatal error: RNifti/NiftiImage_print.h: No such file or directory
   24 | #include "RNifti/NiftiImage_print.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [<builtin>: niftilib/nifti1_io.o] Error 1

At this point I'm not sure how to proceed, though I'm still looking into it. Is there anything am I missing? Was I wrong to change the include lines in the standalone directory?

Edit:
I added an include in the makefile to solve not finding the RNifti header.

CFLAGS += -I. -I../inst/include
CXXFLAGS += -I. -I../inst/include

I noticed other #include statement missing in the standalone directory source files:

• znzlib/*
• zlib/*
• niftilib/*
• RNifti.h

Finally, it seems to compile

RNifti-1.5.1/standalone$ make all
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o niftilib/nifti1_io.o niftilib/nifti1_io.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o znzlib/znzlib.o znzlib/znzlib.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/adler32.o zlib/adler32.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/compress.o zlib/compress.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/crc32.o zlib/crc32.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/deflate.o zlib/deflate.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/gzclose.o zlib/gzclose.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/gzlib.o zlib/gzlib.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/gzread.o zlib/gzread.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/gzwrite.o zlib/gzwrite.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/infback.o zlib/infback.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/inffast.o zlib/inffast.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/inflate.o zlib/inflate.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/inftrees.o zlib/inftrees.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/trees.o zlib/trees.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/uncompr.o zlib/uncompr.c
cc -I. -I../inst/include -DNDEBUG -DHAVE_ZLIB  -c -o zlib/zutil.o zlib/zutil.c
g++ -DNDEBUG -DHAVE_ZLIB -I. -I../inst/include  -o nii_info nii_info.cpp niftilib/nifti1_io.o znzlib/znzlib.o zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/deflate.o zlib/gzclose.o zlib/gzlib.o zlib/gzread.o zlib/gzwrite.o zlib/infback.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/trees.o zlib/uncompr.o zlib/zutil.o
g++ -DNDEBUG -DHAVE_ZLIB -DRNIFTI_NIFTILIB_VERSION=2 -DNO_REMAP_NIFTI2_FUNCTIONS -I. -I../inst/include  -o nii2_info nii_info.cpp niftilib/nifti2_io.o znzlib/znzlib.o zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/deflate.o zlib/gzclose.o zlib/gzlib.o zlib/gzread.o zlib/gzwrite.o zlib/infback.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/trees.o zlib/uncompr.o zlib/zutil.o

[Timothy-Anders0n]

Now when it comes to using the library in code, it seems I run into a problem with RNifti::RNiftiImageData::Iterator.

short version of code:

#include "RNifti.h"

void main()
{
    RNifti::NiftiImage image("~/test_nifti.nii", false);
}

Error:

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\xutility:1279: error: C2280: 'RNifti::NiftiImageData::Iterator &RNifti::NiftiImageData::Iterator::operator =(const RNifti::NiftiImageData::Iterator &)': attempting to reference a deleted function
C:\pathToMyCode\external\RNifti\include\RNifti/NiftiImage.h(418): note: compiler has generated 'RNifti::NiftiImageData::Iterator::operator =' here
C:\pathToMyCode\external\RNifti\include\RNifti/NiftiImage.h(418): note: 'RNifti::NiftiImageData::Iterator &RNifti::NiftiImageData::Iterator::operator =(const RNifti::NiftiImageData::Iterator &)': function was implicitly deleted because 'RNifti::NiftiImageData::Iterator' has a data member 'RNifti::NiftiImageData::Iterator::parent' of reference type
C:\pathToMyCode\external\RNifti\include\RNifti/NiftiImage.h(355): note: see declaration of 'RNifti::NiftiImageData::Iterator::parent'
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\xutility(1279): note: the template instantiation context (the oldest one first) is
C:\pathToMyCode\external\RNifti\include\RNifti/NiftiImage.h(468): note: see reference to function template instantiation '_OutIt std::copy<RNifti::NiftiImageData::Iterator,RNifti::NiftiImageData::Iterator>(_InIt,_InIt,_OutIt)' being compiled
        with
        [
            _OutIt=RNifti::NiftiImageData::Iterator,
            _InIt=RNifti::NiftiImageData::Iterator
        ]
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\xutility(4611): note: see reference to function template instantiation 'void std::_Seek_wrapped<_OutIt,_OutIt>(_Iter &,_UIter &&)' being compiled
        with
        [
            _OutIt=RNifti::NiftiImageData::Iterator,
            _Iter=RNifti::NiftiImageData::Iterator,
            _UIter=RNifti::NiftiImageData::Iterator
        ]

[jonclayden]

Hi. It shouldn't be necessary to mess with include paths or preprocessor directives if you build from the repo's standalone directory. From what you say it sounds like the symlinks are broken – did you perhaps create a copy of the standalone directory without following the symlinks?

[Timothy-Anders0n]

Thanks for the quick reply! I don't know what caused this but I tried both with master and with the latest release without copying the standalone directory. Just placing myself in the directory then using make. Fixing the include paths to add the #include directive was enough to make it work though so I haven't looked into why it does not work with just ../../path/to/header on my computer (WSL2 Ubuntu 22.04).

Right now I'm trying to see why the RNifti::NiftiImage image("~/test_nifti.nii", false); gives me a C2280 error: attempting to reference a deleted function. Any idea? No hurry though and thanks for all the good work :) Nifticlib is such a pain to work with lol

Re-reading your comment, I'm wondering if you mean that the files in the standalone directory are meant to be symbolic links of the files in inst/include and src/? Because if so, I am sure that when I git clone master / when I download the .zip of the release, I get hard files instead of symbolic links (though the only line of content is a ../path/to/proper/file.ext)

EDIT:
the whole thing with error C2280 seems to only be present on my Windows compilation of the code I'm working on. When I compile it on my linux, that error isn't there. I'm using the Qt's QMake and MSVC 19 to compile my project on Windows and QMake and [I need to check] on Linux. Using your nii_info executable works whether it was compiled with make on Windows or Linux. So I don't the details yet but it seems to be an issue specific to Windows. I'll investigate a bit when I'll have more time. :)

[jonclayden]

OK, I doubt I can replicate your build environment, but from the error you quote above, and Microsoft's compiler documentation, I can understand what it's driving at, but the details depend a bit on their implementation of std::copy(). That's awkward, because the suggested workaround is "change your logic to remove the assignment operations that cause the error", but I can't do that if it arises in library code. All in all, this gets into the weeds a bit.

[jonclayden]

As for the symlinks issue, I must admit that this is mainly my oversight. My understanding was that NTFS supported them, so I assumed they would be used by Git as needed, but it seems that's not the case unless you go out of your way. Specifically, you need to enable Developer Mode in Windows settings and ensure you have support for them on the Git side via

git config core.symlinks true

I could add a note about this to the README in the standalone directory (simple enough, but maybe clunky for Windows devs) or copy the files rather than linking them (which will work everywhere but is repetitive and means I'll need a mechanic to keep the copies up to date with the canonical versions). Any thoughts? Is there a better third option?

[Timothy-Anders0n]

Thanks a lot for looking into it :) this is truly appreciated and for the std::copy issue I will look into it (I don't know how you found the answer; I had been looking for it for so long lol). For the fix, I'll start looking into another workaround and I'll let you know if I find anything. It shouldn't be that a code that works fine just doesn't compile into usable libraries for windows lol. It may be possible to add a /if target environment Windows/ macro where the implementation changes to bypass the error altogether.

For the symlinks, my solution was to change the path inside from a .../path/to/file to an #include ".../path/to/file" and it worked. I think I had prepared enough for a PR but I wasn't sure if you accepted PR and if you were to change that logic especially when it seemed I was the only one with the issue.

I can prepare a PR with all the link files changed appropriately while making sure it compiles on Linux and Windows on my side if you'd like.

[jonclayden]

There is a requirement that iterators be copy-assignable, and the reference member violates that requirement. I was previously unaware of this combination of factors, but it is on me, and I can replicate the compiler error if I put an explicit copy assignment somewhere in the code. I'll commit a short-term fix, probably switching to a pointer internally, and think about whether there's a better approach long-term.

[jonclayden]

On the symlinks, using include statements is a neat workaround, but it won't work if the files are copied out of tree, and that is one aim of the standalone directory.

[Timothy-Anders0n]

I'm not sure which files you mean when you're talking about copying out of tree (because of my ignoring in software deployment and such). I'll assume you mean copying the header files from the standalone directory after building.

The makefile I've been using so far has been the following:
Makefile_unix.zip

In it, the line

FIND_INC = find . -maxdepth 1 -type f -name \*.h -exec cp {} build/include/{} \;

serves the purpose of copying the header files found within the standalone directory and paste them into the build/include directory following the same architecture as they have within standalone, e.g. nifticlib/nifti1_io.h' -> build/include/nifticlib/nifti1_io.h. This works because I've lazily copied the original header files from RNifti/inst/includeinto thestandalone` directory.

So, here is my take on the issue of copying the files out of tree.

MKDIR_P = mkdir -p
AR = ar -rcs
FIND_INC = find ../inst/include -maxdepth 1 -type f -name \*.h -exec cp {} build/include/{} \;

[...]

libRNifti:
	${MKDIR_P} build/lib
	${AR} build/lib/libRNifti.a $(NIFTILIB1_OBJECTS) $(NIFTILIB2_OBJECTS) $(ZLIB_OBJECTS)

.PHONY: INCLUDES
INCLUDES: $(./include)
	${MKDIR_P} build/include/niftilib build/include/zlib build/include/znzlib build/include/RNifti
	${FIND_INC}

(I've also added the making of the library file libRNifti.a since I don't know how else one can integrate the RNifti library into a code beyond adding all the header and source files to their project. I only made a static library in my makefile because of the specifications of my project but of course one can distribute both static and dynamic files or leave the user with the choice, same for the location of the build directory).

[jonclayden]

I've committed a fix for the code issue. If you're able to check whether the latest commit resolves the C2280 compiler error, that would be much appreciated.

[Timothy-Anders0n]

I've committed a fix for the code issue. If you're able to check whether the latest commit resolves the C2280 compiler error, that would be much appreciated.

The C2280 compiler error is resolved indeed 🥳, now I'm running into issues from using the MSVC compiler after having compiled your library using MinGW's cross compiler from my WSL distribution haha.

I remembered that to make it work with the windows compiler I had to add include lines in various files and somehow also add namespaces in front of many of the RNiftiImage classes in the _impl.h file. Nothing that was impossible so definitely not a priority since the library is still able to be built for windows though :)

Thanks for your help and finding where the problem with the Iterator was and fixing it so quickly :)

[Timothy-Anders0n]

For people who may come across this issue:

I ended up using Visual Studio's cl.exe to compile the .obj files and lib.exe to make the RNifti.lib file. Then, I added the newly built .lib file to my project instead of the previous one built with MinGW.

At first, I wasn't able to compile my project using the library (LNK1169: one or more multiply defined symbols found) because I was compiling the library using both nifticlib's nifti2_io.obj and nifti1_io.obj . Removing nifti2_io.obj from the list when creating the library was enough to get rid of that error and the project was compiling just fine. :)

Ultimately, I don't recommend compiling using MSVC lol I achieved the same results with much fewer struggles using WSL's MinGW cross compiler...

[jonclayden]

Standalone building on Windows is now properly supported, and included in the package's CI, through an nmake-compatible makefile. There are also no longer any symlinks in the repository; instead they're created when needed, by symlinking on Unix-alikes and copying on Windows.

This was a learning experience! Thanks for the prompt.