Linking error - repeated symbols when splitting into modules #4485

andreaferretti opened this Issue Jul 13, 2016 · 3 comments


None yet

3 participants

andreaferretti commented Jul 13, 2016 edited

I have tried splitting my Emmy library into modules, thus moving from this version where everything is included

import sequtils, math, intsets, algorithm, macros, tables, bigints

include private/structures
include private/pairs
include private/modular
include private/operations
include private/tableops
include private/quotient
include private/polynomials
include private/linear
include private/primality

to this version, where everything is imported

import emmy/structures, emmy/pairs, emmy/modular, emmy/operations,
  emmy/tableops, emmy/quotient, emmy/polynomials, emmy/linear,

export structures, pairs, modular, operations, tableops, quotient,
  polynomials, linear, primality

and consequently adding relative imports between modules.

The first version works fine: one can see that by checking out the master branch and running nimble tests.

The one where I split everything into modules now fails to link: one can see that by checking out the modules branch and running nimble tests.

It seems that by having the procedures defined in different modules, there are repeated symbols in the generated code, and the linker gets confused

The errors are really long, but they all look like

tests/nimcache/emmy_primality.o: In function `addInt':
/home/andrea/workspace/Nim/lib/system/arithm.nim:320: multiple definition of `T105763075_13'
tests/nimcache/emmy_primality.o:/home/andrea/workspace/Nim/lib/system/arithm.nim:320: first defined here
mbaulch commented Jul 17, 2016

I don't think this code should compile. The emmy/primality module and others are defined in the emmy and tests directories, because of the --path:. flag passed by your nimble tests task. There are ways around this, but AFAIK there isn't a sensible way for the compiler to support such naming conflicts. Have proposed a fix #4495.


Thank you, I did not realize that the issue was the test modules being named the same way as the core modules. This is enough to solve the problem for me: I can just rename the test modules to something else.

Still, there is something I do not understand: it seems to me that the core modules have absolute names such as emmy/primality, while the test ones are just primality. Should not there be some name mangling done by the compiler to ensure that these get compiled without ambiguity?

mbaulch commented Jul 17, 2016

That's a good plan. If you're stuck for ideas, the Nim compiler tests use the t prefix; so tprimality, tlinear etc. would be consistent with that.

tests/primality.nim defines a module called primality living in emmy: i.e. emmy/primality. The tests directory itself doesn't actually create a module. Both modules are trying to occupy the same point in the namespace. I'm not sure how mangling can help.

As @Araq said (in #4495 (comment)):

Filenames need to be unique per Nimble-package.

@Araq Araq added a commit that closed this issue Jul 19, 2016
@Araq Araq fixes #4485; package handling works better; docgen works with --proje…
…ct on Nimble package level
@Araq Araq closed this in 9eb909b Jul 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment