Nana UI Library

[mearvk]

Nana uses the basic_types.hpp for nana::rectangle and others. Trying to compile this into a libnana.a I find leaves the source code in the .hpp file out. The hpp file is - I suspect - not getting compiled into any .o object file.

Afterwards I get a linker error (ld) saying it cannot find these references in particular. I'm stumped; using Netbeans 8.2 I get nowhere with this.

I think the issue is that the static library will not have compiled in the basic_types.hpp file and so the linker will always complain about missing values.

I've asked on the Nana forums and they've suggested that it's probably a Netbean or g++ configuration issue.

Can you guys see about helping me on this one? It's run on Windows 10 and MinGW for compatibility and it's simply tuff.

Thanks.

[MikeyBoy]

An extention of .hpp file usually indicates a header file. It's supposed to be #included in any translation unit that needs to use the things that are defined in it, rather than compiled into its own translation unit and linked against.

[mearvk]

I think I agree. It would be very unusual to find this out of order in a library. What could I understand here? I really need this gone, closed. - off my desk.

[helios]

What are the actual errors you're getting? The linker doesn't even know about .hpp files, so the presence or absence of one should make literally no difference, as far as the linker is concerned.

[salem c]

The header files in question contain at least one template.

Templates are expanded inline with the appropriate substitutions at compile time.

Like for example when you say vector<int> myVector;
Large chunks of the STL are templated files.

You can't create libraries out of templates, because there's no way to create every possible instantiation in advance.

[mearvk]

The build output looks like:

...

build/Release/MinGW64-Windows/NanaBrowser.o:NanaBrowser.cpp:(.text+0x4b): undefined reference to `nana::rectangle::rectangle()'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x213a): undefined reference to `nana::rectangle::rectangle(int, int, unsigned int, unsigned int)'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x2142): undefined reference to `nana::rectangle::empty() const'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x3a02): undefined reference to `nana::rectangle::dimension(nana::size const&)'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x3a0f): undefined reference to `nana::rectangle::empty() const'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x3ccd): undefined reference to `nana::size::size(unsigned int, unsigned int)'
../../../../../MinGW/lib/libnana.a(place.o):place.cpp:(.text+0x3cd9): undefined reference to `nana::rectangle::dimension(nana::size const&)'

The nana::rectangle, nana::size etc. are in the basic_types.hpp. I'm unsure if it's configured correctly in Netbean 8.2 however.

Two things occur to me:

1. We must be able to ask Netbeans to include the hpp files in this case where certain structs and classes exist without cpp relations.

2. We must be able to ask the linker (ld in this case) to include the hpp files as part of the linking process.

What jumps out at you here?

[mearvk]

Also, rather finally, we do see the basic_types.hpp is included in the cpp files where appropriate. This would seem to indicate that the .o and resulting .a files have the appropriate header file(s) reference(s).

...

Library Files/libnana.a(native_paint_interface.o):native_paint_interface.cpp:(.text+0x19): undefined reference to `__imp_GetObjectW'
Library Files/libnana.a(native_paint_interface.o):native_paint_interface.cpp:(.text+0x2c): undefined reference to `nana::size::size(unsigned int, unsigned int)'
Library Files/libnana.a(native_paint_interface.o):native_paint_interface.cpp:(.text+0x46): undefined reference to `nana::size::size()'

...

On digging we find the native_paint_interface.cpp does have via its direct hpp include a reference to basic_types.hpp. This would seem to conclude the issue as correctly drawn from the standpoint of the g++ compiler. However we are left with something here which trips the linker or something left in the compiler.

Ok.

[helios]

2. We must be able to ask the linker (ld in this case) to include the hpp files as part of the linking process.

Like I said, the linker doesn't know or care about .hpp files. It doesn't even care about .cpp files. All it can see is .o/.obj and .a/.lib.

It sounds like the problem is that you're not linking your program to the nana import/static library. How did you obtain the library? Did you download sources, binaries, or did you install it via a package manager?

[mearvk]

We compiled the libnana.a via Netbeans 8.2. It does have references for the static library build to all the headers. However when we try to use the static library (libnana.a) the g++ command fails to find appropriate connection in the final g++ compilation.

I am unsure on it; g++ is supposedly for linux and the MinGW and all this is easily confused with c:/dir/subdir. Let me know what else I could try.

Thanks. Consider this closed if nothing else occurs to you.