I must admit I'm not too familiar with the options here. Although I'm not sure if it's directly related, it might not help that CRC32c has multiple implementations.
There seems to be a discussion on this kind of issue below, where they state the limitations of select and depend. In particular, they state that depend doesn't work in this situation, and that select can have issues if the subsystem has its own dependencies:- http://lkml.indiana.edu/hypermail/linux/kernel/0804.3/1596.html It seems like in this case though, subsystem dependencies shouldn't be an issue. ext4 seems to set the precedent by selecting CRYPTO and CRYPTO_CRC32C: http://patchwork.ozlabs.org/patch/134815/ So it seems like we should make it select CRC32C if this module is statically compiled. How does that sound? On Sun, Aug 25, 2013 at 2:36 PM, Jesse Gross <je...@nicira.com> wrote: > On Fri, Aug 23, 2013 at 6:16 PM, kbuild test robot > <fengguang...@intel.com> wrote: > > tree: git:// > git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master > > head: 810ddb4f57166b11e68291c33162007c394dbb7b > > commit: e1fa7d46ca3e698691cb1514bb4610d46e78bbd9 [9/10] openvswitch: Add > SCTP support > > config: i386-randconfig-c08-0820-0823 (attached as .config) > > > > All error/warnings: > > > > net/built-in.o: In function `execute_set_action': > >>> actions.c:(.text+0xa5cb5): undefined reference to `crc32c' > >>> actions.c:(.text+0xa5cd0): undefined reference to `crc32c' > >>> actions.c:(.text+0xa5cf2): undefined reference to `crc32c' > >>> actions.c:(.text+0xa5d21): undefined reference to `crc32c' > >>> actions.c:(.text+0xa5d7d): undefined reference to `crc32c' > > net/built-in.o:actions.c:(.text+0xa5d98): more undefined references > to `crc32c' follow > > Joe, this is from a direct cross port that I did from your out-of-tree > module patches to my upstream tree. It's occurring when the OVS module > is statically compiled in and the CRC32 code is a module, which > results in a dependency problem. > > This issue obviously doesn't exist for the out of tree module since it > can never be compiled in. How would you like to handle it upstream? >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
