gnucap-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]