Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to compile external files with same name as module. #3072

Closed
Angluca opened this issue Jul 6, 2015 · 13 comments

Comments

Projects
None yet
8 participants
@Angluca
Copy link

commented Jul 6, 2015

Hi, I learn it write some code.
C invocation example

I don't know why build it error, I use nim 0.11.2 at osx 10.10 (rmbp13).
Echo error:

== test.c ==
int csum(int n) {
    if(n <= 0) return 0;
    return n + csum(n - 1);
}
== test.nim ==
{.compile: "test.c".}
proc csum(n: cint): cint {.importc.}
echo csum(100)

== build info ==
nim c test.nim
[Linking]
Undefined symbols for architecture x86_64:
  "_csum", referenced from:
      _testInit in test.o
      _testInit in test.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: execution of an external program failed

== nim version ==
Nim Compiler Version 0.11.2 (2015-05-04) [MacOSX: amd64]

But this code can be compiled successfully.

proc printf(formatstr: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
printf("%d, %f, %s\n", 11, 33.3, "test")
@apense

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2015

It's resulting from the C file having the same name as the Nim file "test." This is probably an error.
Try renaming the C file to "testc.c" or something in the meantime 😃 (this fixes it on my Win64).

FYI: the "test.nim" file is compiled down to "test.c". The compiler is probably mixing up that file with your own "test.c"

@Angluca

This comment has been minimized.

Copy link
Author

commented Jul 7, 2015

Oh! You are right, It's ok now, Thank you.
Hope fix it in after version.

@Angluca Angluca closed this Jul 7, 2015

@apense

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2015

Could you reopen it? Maybe make the title something like "Unable to compile external files with same name as module." You found a good issue. I don't think it's addressed anywhere.
EDIT: it should at least be mentioned in the documentation

@Angluca Angluca reopened this Jul 7, 2015

@Angluca Angluca changed the title link c code: Undefined symbols for architecture x86_64 Unable to compile external files with same name as module. Jul 7, 2015

@refi64

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2015

Would a simple fix be to compile .nim files as .nim.c?

@dom96 dom96 added the Path Handling label Jan 16, 2016

@shaunc

This comment has been minimized.

Copy link

commented Feb 16, 2016

+1 -- just hit this, and seems important for scalability: if you have a large tree of modules from various sources, its alot of coupling to force all modules to share the same namespace regardless of path.

Also, this is probably important for nim-lang/nimble#131

@Varriount

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2016

@shaunc any ideas for a solution?

@shaunc

This comment has been minimized.

Copy link

commented Feb 16, 2016

@Varriount -- name munging? Perhaps simplest would be just to have a counter for each module and prefix or suffix that counter to the module name, then rewrite references to it. This is the approach that babel uses to transpile es6 imports to es5 in javascript.

@Araq

This comment has been minimized.

Copy link
Member

commented Feb 17, 2016

The compiler uses pkg_module.c if you use a pkg.nimble file. It scales perfectly well if you use Nimble packages.

@shaunc

This comment has been minimized.

Copy link

commented Feb 17, 2016

@Araq -- the thrust of nim-lang/nimble#131 (as I would like to see it anyway) is to avoid any unnecessary coupling between package version decisions. (There is necessary coupling, sometimes -- enforceable with something like npm/peerDependencies.) So if package x has a sub-dependency w/ version 1.0.0 of package z, and package y uses version 2.0.0 of z, a project can use both x and y without problems and they are linked to the appropriate versions of z.

Is there a mechanism to manage this (x_z_module.c vs y_z_module.c)? If not, I think there still is a scalability issue. The beauty of npm is that major projects can have 100s of dependencies nested 5 or 6 levels deep, and everything still works even if all the package maintainers don't move in lockstep to support new versions of subdependencies. This makes it much less costly/risky to hive off subdependencies, which is exactly what happens. These simpler sub-pieces attract community support more easily.

@Araq

This comment has been minimized.

Copy link
Member

commented Feb 17, 2016

If not, I think there still is a scalability issue.

Well I left the issue open for a reason.

@shaunc

This comment has been minimized.

Copy link

commented Feb 18, 2016

Thanks so much for nim! :) ... I'm learning nim because I need to write a custom index library for in-memory distributed analytics. Not anything I should do in js or python and this seems way faster than c++ development. "Scalability" in terms of hoards of developers working simultaneously on 1000s of projects is a problem I wish on you. :)

@narimiran

This comment has been minimized.

Copy link
Member

commented Feb 10, 2019

Works in Nim 0.19.9

@narimiran narimiran closed this Feb 10, 2019

@shaunc

This comment has been minimized.

Copy link

commented Feb 10, 2019

Awesome! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.