[PATCH] Linux compilation fixes

[GoogleCodeExporter]

nvtt trunk does not compile in Linux (gcc-4.8, Linux Mint 16).

I'm attaching a patch that fixes the issue.

Patch comments for things that might not be obvious:

1. NV_FORCEINLINE needs to have an inline to avoid multiple definition errors 
during linking.

2. DirectDrawSurface.cpp: If you use a function from Vector.h but fail to 
include Vector.inl you get confusing 'unresolved symbol' errors when linking 
executables; the error is impossible to trace to the source file since it looks 
like this:

Linking CXX executable nv-gnome-thumbnailer
../../nvimage/libnvimage.so: undefined reference to `nv::Vector4::Vector4()'
../../nvimage/libnvimage.so: undefined reference to 
`nv::Vector4::Vector4(nv::Vector4 const&)'

Only happens in Release mode because in Debug the symbol usually happens to be 
compiled into some other translation unit.

This header design is horribly wrong. It looks like Vector.cpp is supposed to 
solve the issue I encountered but of course it does not - since symbols are 
declared as inline in this file they are stripped from the object file in 
Release mode.

3. nvimage now uses BC7 decoding. This is an API layering violation; this means 
that now you have to link in nvtt whenever you need nvimage, so all tools have 
to depend on it -- and obviously BC6H/BC7 code needs to be compiled in.

Regardless, after attached changes I can actually build nvtt in both debug and 
release and the tools work (at least nvcompress does). I have not checked if 
BC6/7 compression works.

Original issue reported on code.google.com by arseny.k...@gmail.com on 25 Dec 2013 at 3:06

Attachments:

• nvtt-linux.patch

[GoogleCodeExporter]

1.- I've changed this back and forth a thousand times. Some gcc versions seem 
to need the inline, others complain about it. I'll change this again, but I 
hope someone figures out what gcc versions need it and which ones don't.

2.- The separation of .h and .inl files allows very fast compilation times. 
This may not matter much for NVTT, but we use NVTT's source code in a much 
larger project that benefits significantly from this separation. Yes, it's 
prone to errors, but if you are familiar with them, these errors are usually 
trivial to fix.

3.- Good point. I should reorganize the directories appropriately, in the 
meantime, I'll apply your workaround.

Original comment by cast...@gmail.com on 21 May 2014 at 5:45

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision r1384.

Original comment by cast...@gmail.com on 21 May 2014 at 5:47

• Changed state: Fixed