Re: link order

On Sat, Jun 29, 2019 at 06:30:23PM +0200, Patrick Mulder wrote:
> setting this:
> 
>   std::map<std::string, CKT_BASE*> * _map = nullptr;
> 
> works fine.

depending on where you put this, it will introduce a memory leak, and
possibly you will lose your dispatcher contents.

(no it really does not make any sense, see my other mails for the
explanation why _map is a pointer in the first place).

> However, the commit
> https://git.savannah.gnu.org/cgit/gnucap.git/commit/?h=pending&id=847095f7965e4f92e8c124817c8f855f560387dd
> 
> seems an interesting option to try also - what do you think, will it make
> sense for this case (MinGW) ?

the commit does not actually fix the link order problem, but intdoduces
a potentially more robust heuristic to detect it + avoids a false
positive compiler warning. feel free to try, but don't expect any
miracles.

> The previous build runs with nullptr until:
> 
> λ cmake --build .
> [ 34%] Built target gnucap
> [ 40%] Built target gnucap-modelgen
> [ 41%] Linking CXX shared module gnucap-default-plugins.dll
> CMakeFiles/gnucap-default-plugins.dir/objects.a(d_admit.cc.obj):d_admit.cc:(.text+0x1c):
> undefined reference to `ELEMENT::ELEMENT(ELEMENT const&)'

okay, now you ran into a real issue with the cmake branch.

look at apps/Make2.g++ vs apps/Make2.mingw32. the upstream makefiles
intended for use on mingw (non-POSIX) linked the plugins against
libgnucap. not a coincidence. this line

LIBS = -lgnucap

(in the ming version) is not required on POSIX.

what you need to do is tell cmake to do this linking, unless the system
is POSIX.  on POSIX, this should be avoided because it it stupid and has
unwanted side effects.

NB: the same addition is needed in the autotools branch, to make it work on
mingw. see autotools/README.

"""
TODO: does not yet work on mingw.
- configure.ac needs to detect condition (see e.g. qucs)
- plugins need to be linked to libgnucap (see e.g. apps/Make2.mingw32
"""

...i simply never had the time or a system to test it.

thanks
felix

_______________________________________________
Gnucap-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel