[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] link order
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] link order |
Date: |
Sat, 29 Jun 2019 18:43:41 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Sat, Jun 29, 2019 at 05:20:41PM +0200, Patrick Mulder wrote:
> I get the problem in the modelgen phase - when trying to compile e.g. the
> diode.
Thanks.
> C:\Users\mulderpa\git\gnucap\build4 (cmake-3 -> origin)
> λ cmake --build .
> [ 34%] Built target gnucap
> [ 40%] Built target gnucap-modelgen
> [ 41%] Generating d_diode.cc
perhaps there is a way to tell cmake to print the commands it is
running. iirc
$ make VERBOSE=1
instead of just "make" does something like that (but prints a lot of
extra stuff, too)
this will be useful to understand how things are actually built.
> @@#
> @@@
> unreachable:C:/Users/mulderpa/git/gnucap/include/l_dispatcher.h:81:install
> build error: link order: dispatcher not yet constructed
[..]
> @@#
> @@@
> unreachable:C:/Users/mulderpa/git/gnucap/include/l_dispatcher.h:41:DISPATCHER_BASE
> build error: link order: constructing dispatcher that already has contents
this is not directly an issue with building a diode model, but a run
time issue with modelgen. modelgen links against libgnucap. libgnucap
has a static dispatcher in it, which must be constructed before anything
else is registered ("installed") to the dispatcher (which is also done
upon loading libgnucap.so).
look at the way libgnucap is constructed ("linked") from a couple of
object files. "globals.o" should come first, and this should have the
desired effect. however, there are some pitfalls. two of them are
- i don't know if cmake messes with the list of files (so have a close
look at the actual linker invocation). if globals.o does not come
first, then this is easy to fix, e.g. avoid cmake, or type in that
command manually. (but don't believe it).
- as Christian pointed out, linking order (or the result of linking)
depends on a bunch of factors, and is not defined in the standard
(how bad...). on some BSD, telling the linker to link globals.o *last*
fixed the problem (theres a mail in the list archive, i can't find
it).
you could at least try to relink libgnucap with the order modified.
there is no guarantee that it will be successful. hideous linkers could
well order things alphabetically, by size or by color, whatever will
make it harder for us.
please, let us know which linker you are using, and if some method fixes
this on your platform.
cheers
felix
- Re: [Gnucap-devel] gnucap build with CMake on Windows, (continued)
- Re: [Gnucap-devel] gnucap build with CMake on Windows, Christian Gagneraud, 2019/06/28
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Re: [Gnucap-devel] link order, Christian Gagneraud, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Re: [Gnucap-devel] link order, Patrick Mulder, 2019/06/29
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/29
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Message not available
- Re: [Gnucap-devel] link order, Felix Salfelder, 2019/06/30
- Message not available
- Re: [Gnucap-devel] link order,
Felix Salfelder <=