<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 11, 2017 at 6:22 AM Boris Kolpackov <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> writes:<br>
<br>
> Passing -fmodules-codegen and -fmodules-debuginfo (I think I'm remembering<br>
> the spelling right) to the step that creates the pcm file will establish<br>
> the right conditions, then passing that pcm file to clang again -c, should<br>
> generate the required object file.<br>
<br>
While I believe the spelling is correct, it still does not work:<br>
<br>
clang++-5.0 -std=c++1z -fmodules-ts -fmodules-codegen -fmodules-debuginfo \<br>
-I.. --precompile -x c++-module -o hello.pcm hello.mxx<br>
<br>
clang: error: unknown argument: '-fmodules-codegen'<br>
clang: error: unknown argument: '-fmodules-debuginfo'<br></blockquote><div><br>Right, sorry - these flags aren't exposed through the driver yet, so for now you can pass them like:<br><br> -Xclang -fmodules-codegen<br> -Xclang -fmodules-debuginfo<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also note that this is not an unresolved symbol but a duplicate:<br></blockquote><div><br>It should work naturally either way, I think. <br><br>Here we go:<br><br> foo.cppm:<br> export module foo;<div> export {</div><div> int f() { return 0; }</div><div> }<br> use1.cpp:<br> import foo;<br> void use1() { f(); }<br> use2.cpp:<br> import foo;<br> void use1();<br> int main() { f(); use1(); }<br><br><font face="monospace"> $ clang++-tot -std=c++1z -fmodules-ts foo.cppm --precompile -o foo.pcm -Xclang -fmodules-codegen</font></div><div><font face="monospace"> $ clang++-tot -std=c++1z -fmodules-ts foo.pcm -c</font></div><div><font face="monospace"> $ clang++-tot -std=c++1z -fmodules-ts -fmodule-file=foo.pcm use1.cpp use2.cpp -c</font></div><div><font face="monospace"> $ nm {foo,use1,use2}.o</font></div><div><font face="monospace"> foo.o:</font></div><div><font face="monospace"> 0000000000000000 T _Z1fv</font></div><div><font face="monospace"> use1.o:</font></div><div><font face="monospace"> 0000000000000000 T main</font></div><div><font face="monospace"> U _Z1fv</font></div><div><font face="monospace"> U _Z4use2v</font></div><div><font face="monospace"> use2.o:</font></div><div><font face="monospace"> U _Z1fv</font></div><div><font face="monospace"> 0000000000000000 T _Z4use2v</font></div><div><font face="monospace"> $ clang++-tot {foo,use1,use2}.o</font></div><div><font face="monospace"> $ ./a.out</font></div><font face="monospace"> $ clang++-tot -std=c++1z -fmodules-ts foo.cppm --precompile -o foo.pcm<br> $ clang++-tot -std=c++1z -fmodules-ts -fmodule-file=foo.pcm use1.cpp use2.cpp -c</font></div><div><font face="monospace"> $ nm {use1,use2}.o</font></div><div><font face="monospace"> use1.o:</font></div><div><font face="monospace"> 0000000000000010 T main</font></div><div><font face="monospace"> 0000000000000000 T _Z1fv</font></div><div><font face="monospace"> U _Z4use2v</font></div><div><font face="monospace"> use2.o:</font></div><div><font face="monospace"> 0000000000000000 T _Z1fv</font></div><div><font face="monospace"> 0000000000000010 T _Z4use2v<br> $ clang++-tot use1.o use2.o</font></div><div><font face="monospace"> use2.o: In function `f()':</font></div><div><font face="monospace"> use2.cpp:(.text+0x0): multiple definition of `f()'</font></div><div><font face="monospace"> use1.o:use1.cpp:(.text+0x0): first defined here</font><br><br>I suppose -fmodules-codegen will be the default for -fmodules-ts sooner or later. (-fmodules-debuginfo is useful too, but you won't see the correctness issue, just debug info size changes)<br><br>It may be that two degrees of -fmodules-codegen would be useful - one that only homes the non-inline functions (external functions become external in the module's object, available_externally in module users objects), and the one we have here that homes all functions (even inline ones, so linkonce_odr functions become weak in the module's object and available_externally in module users objects).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
clang++-5.0 -std=c++1z -fmodules-ts -I.. --precompile -x c++-module -o hello.pcm hello.mxx<br>
clang++-5.0 -std=c++1z -fmodules-ts -I.. -fmodule-file=hello.pcm -c hello.cxx<br>
clang++-5.0 -std=c++1z -fmodules-ts -I.. -fprebuilt-module-path=. -c driver.cxx<br>
clang++-5.0 -std=c++1z -fmodules-ts -I.. -o driver driver.o hello.o<br>
hello.o: In function `hello::non_inline()':<br>
hello.cxx:(.text+0x0): multiple definition of `hello::non_inline()'<br>
driver.o:driver.cxx:(.text+0x0): first defined here<br>
<br>
Thanks,<br>
Boris<br>
</blockquote></div></div>