http://bugzilla.suse.com/show_bug.cgi?id=1037309 http://bugzilla.suse.com/show_bug.cgi?id=1037309#c5 --- Comment #5 from Tomáš Chvátal <tchvatal@suse.com> --- (In reply to zhen ren from comment #4)
Hi!
(In reply to Tomáš Chvátal from comment #3)
Hmm, it seems upstream is a bit funny there.
I will check the commits between the version 168 and 170.
You can compile separate lockd as we do but it won't be loaded.
You mean splitting lockd out from lvm2-clvm? Sorry, but what do you mean by "it won't be loaded"?
We compile lockd as a separate package, but the main files are provided in lvm2.spec Those main files like vgcreate are compiled with LVMLOCKD_SUPPORT=0
If you check the .h file it states for the LVMLOCKD_SUPPORT undefined to inline those functions (see 'static inline') on the declarations.
Yes, macro LVMLOCKD_SUPPORT should be "1" so that the real code can be compiled in.
Unless I am mistaken this means for the compiler to actually put the code in the binary rather than issue follow up call for the function later on.
Yes, the problem is, i think, why LVMLOCKD_SUPPORT is not "1"? I'm not familiar with make-auto tools, but I will dig more.
It is correctly 0 for the vgcreate and others as per above. Problem is that this header file is written in such a way that it breaks if you try to overload the function later on to actually allow the loading of the full proper lockd functions. The detection like this should not be decided by the compilation flag but done in runtime like in clvm... Something like https://build.opensuse.org/package/view_file/Base:System/lvm2/pvmove_support... And of course the header must not inline those functions in either case. -- You are receiving this mail because: You are on the CC list for the bug.