Skip to content

Need clarifications on --lib-create #3780

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

Closed
poemonsense opened this issue Nov 25, 2022 · 5 comments · Fixed by #3785
Closed

Need clarifications on --lib-create #3780

poemonsense opened this issue Nov 25, 2022 · 5 comments · Fixed by #3785
Labels
resolution: fixed Closed; fixed

Comments

@poemonsense
Copy link
Contributor

I'm using verilator to create static and dynamic libraries that can be linked with other files for simulation. However, I'm noticing some behavior changes from v4.218 to v5.002-89-ga83ed6b06.

In v4.218, if I specify user-provided cpp files to verilator and specify --lib-create SimTop --exe, verilator creates the Makefile as follows: libSimTop.so: $(VK_OBJS) $(VK_GLOBAL_OBJS) SimTop.o $(VM_HIER_LIBS).

In v5.002, with the same options, it would create as libSimTop.so: $(VK_OBJS) $(VK_USER_OBJS) $(VK_GLOBAL_OBJS) SimTop.o $(VM_HIER_LIBS). That is, v5.002 links the user-specified cpp files together with verilator-generated cpp files.

If I don't pass the --exe option to verilator, both versions create the Makefile without $(VK_USER_OBJS).

So I'm wondering what's the expected correct behavior of the --lib-create. Shouldn't it include all the cpp files specified by the user? I prefer that verilator automatically links then together because the user does inform verilator of these extra cpp files. In this way, the user leaves these specified cpp files to verilator without the need to compile them manually.

If so, should verilator links the user objects even without --exe? If not, though I think it's better to have this behavior, I assume there should be some regression between v4.218 and v5.002?

@poemonsense poemonsense added the new New issue not seen by maintainers label Nov 25, 2022
@poemonsense
Copy link
Contributor Author

I think the user should not use --exe along with --lib-create concurrently. I'm just using them together for a workaround to let verilator deal with the cpp files for me.

@wsnyder wsnyder added status: ready Issue is ready for someone to fix; then goes to 'status: assigned' and removed new New issue not seen by maintainers labels Nov 27, 2022
@wsnyder
Copy link
Member

wsnyder commented Nov 27, 2022

For background see #3370 #3382. I agree using --exe with --lib-create probably doesn't matter, perhaps you'd like to make a pull request to flag that as an error (long with a test)?

@poemonsense
Copy link
Contributor Author

poemonsense commented Nov 28, 2022

Thanks. I see that the --lib-create includes the user objects in #3382. However, in v5.002, when I'm using --lib-create alone without --exe, it does not include the user-specified cpp files?

Let me confirm it and check the verilator source files today. I'll try a PR for the arguments.

@poemonsense
Copy link
Contributor Author

I think there're two separated issues.

First, Verilator does not generate the make rules for user-specified cpp files and objects. The error info with master branch of verilator is like the following:

make[3]: *** No rule to make target 'cppName.o', needed by 'libName.a'.  Stop.

I've opened a PR #3784 to fix that. Please help take a look.

Second, using --exe with --lib-create is a little bit strange, as there would be main function in the source files which would cause errors when linked with other libs. I'll try a PR later for this case.

@poemonsense
Copy link
Contributor Author

I've opened a second PR #3785 to disable using --exe together with --lib-create.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: fixed Closed; fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants