From: Randy Dunlap <rdunlap@infradead.org> To: David Teigland <teigland@redhat.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au>, swhiteho@redhat.com, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, cluster-devel@redhat.com Subject: Re: linux-next: Tree for May 8 (dlm) Date: Thu, 09 May 2013 10:08:54 -0700 [thread overview] Message-ID: <518BD826.4040403@infradead.org> (raw) In-Reply-To: <20130509165028.GA18077@redhat.com> On 05/09/13 09:50, David Teigland wrote: > On Thu, May 09, 2013 at 09:47:45AM +1000, Stephen Rothwell wrote: >> [Just forwarding to David ...] >> >> On Wed, 08 May 2013 11:04:45 -0700 Randy Dunlap <rdunlap@infradead.org> wrote: >>> >>> on x86_64: >>> >>> when CONFIG_GFS2_FS_LOCKING_DLM=y and CONFIG_DLM=m: >>> >>> fs/built-in.o: In function `gfs2_lock': >>> file.c:(.text+0xa512c): undefined reference to `dlm_posix_get' >>> file.c:(.text+0xa5140): undefined reference to `dlm_posix_unlock' >>> file.c:(.text+0xa514a): undefined reference to `dlm_posix_lock' > > gfs2/file.c calls the dlm directly, so I suppose gfs2 itself needs > to depend on the dlm. It's been like this for a long time, so I > don't know why it only appeared now. Agreed to both statements. >>> fs/built-in.o: In function `gdlm_cancel': >>> lock_dlm.c:(.text+0xb3f57): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `gdlm_unmount': >>> lock_dlm.c:(.text+0xb40ff): undefined reference to `dlm_release_lockspace' >>> fs/built-in.o: In function `sync_unlock.isra.4': >>> lock_dlm.c:(.text+0xb420d): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `sync_lock.isra.5': >>> lock_dlm.c:(.text+0xb42d9): undefined reference to `dlm_lock' >>> fs/built-in.o: In function `gdlm_put_lock': >>> lock_dlm.c:(.text+0xb45e7): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `gdlm_mount': >>> lock_dlm.c:(.text+0xb4928): undefined reference to `dlm_new_lockspace' >>> lock_dlm.c:(.text+0xb4c75): undefined reference to `dlm_release_lockspace' >>> fs/built-in.o: In function `gdlm_lock': >>> lock_dlm.c:(.text+0xb529f): undefined reference to `dlm_lock' > > lock_dlm.c is GFS2_FS_LOCKING_DLM which depends on DLM. > Is that not correct? The problem is that GFS2_FS_LOCKING_DLM is a bool. It depends on DLM, which is a tristate with a value of 'm', so the bool is true (as long as DLM != 'n'). One option is to make GFS2_FS_LOCKING_DLM depend on "DLM != n", but a better fix is to make GFS2_FS depend on DLM, like you said above. -- ~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org> To: cluster-devel.redhat.com Subject: [Cluster-devel] linux-next: Tree for May 8 (dlm) Date: Thu, 09 May 2013 10:08:54 -0700 [thread overview] Message-ID: <518BD826.4040403@infradead.org> (raw) In-Reply-To: <20130509165028.GA18077@redhat.com> On 05/09/13 09:50, David Teigland wrote: > On Thu, May 09, 2013 at 09:47:45AM +1000, Stephen Rothwell wrote: >> [Just forwarding to David ...] >> >> On Wed, 08 May 2013 11:04:45 -0700 Randy Dunlap <rdunlap@infradead.org> wrote: >>> >>> on x86_64: >>> >>> when CONFIG_GFS2_FS_LOCKING_DLM=y and CONFIG_DLM=m: >>> >>> fs/built-in.o: In function `gfs2_lock': >>> file.c:(.text+0xa512c): undefined reference to `dlm_posix_get' >>> file.c:(.text+0xa5140): undefined reference to `dlm_posix_unlock' >>> file.c:(.text+0xa514a): undefined reference to `dlm_posix_lock' > > gfs2/file.c calls the dlm directly, so I suppose gfs2 itself needs > to depend on the dlm. It's been like this for a long time, so I > don't know why it only appeared now. Agreed to both statements. >>> fs/built-in.o: In function `gdlm_cancel': >>> lock_dlm.c:(.text+0xb3f57): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `gdlm_unmount': >>> lock_dlm.c:(.text+0xb40ff): undefined reference to `dlm_release_lockspace' >>> fs/built-in.o: In function `sync_unlock.isra.4': >>> lock_dlm.c:(.text+0xb420d): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `sync_lock.isra.5': >>> lock_dlm.c:(.text+0xb42d9): undefined reference to `dlm_lock' >>> fs/built-in.o: In function `gdlm_put_lock': >>> lock_dlm.c:(.text+0xb45e7): undefined reference to `dlm_unlock' >>> fs/built-in.o: In function `gdlm_mount': >>> lock_dlm.c:(.text+0xb4928): undefined reference to `dlm_new_lockspace' >>> lock_dlm.c:(.text+0xb4c75): undefined reference to `dlm_release_lockspace' >>> fs/built-in.o: In function `gdlm_lock': >>> lock_dlm.c:(.text+0xb529f): undefined reference to `dlm_lock' > > lock_dlm.c is GFS2_FS_LOCKING_DLM which depends on DLM. > Is that not correct? The problem is that GFS2_FS_LOCKING_DLM is a bool. It depends on DLM, which is a tristate with a value of 'm', so the bool is true (as long as DLM != 'n'). One option is to make GFS2_FS_LOCKING_DLM depend on "DLM != n", but a better fix is to make GFS2_FS depend on DLM, like you said above. -- ~Randy
next prev parent reply other threads:[~2013-05-09 17:09 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-08 4:01 linux-next: Tree for May 8 Stephen Rothwell 2013-05-08 4:01 ` Stephen Rothwell 2013-05-08 17:57 ` linux-next: Tree for May 8 (gpio-mcp23s08) Randy Dunlap 2013-05-08 18:04 ` linux-next: Tree for May 8 (dlm) Randy Dunlap 2013-05-08 18:04 ` [Cluster-devel] " Randy Dunlap 2013-05-08 23:47 ` Stephen Rothwell 2013-05-08 23:47 ` [Cluster-devel] " Stephen Rothwell 2013-05-09 16:50 ` David Teigland 2013-05-09 16:50 ` [Cluster-devel] " David Teigland 2013-05-09 17:08 ` Randy Dunlap [this message] 2013-05-09 17:08 ` Randy Dunlap 2013-05-13 9:18 ` Steven Whitehouse 2013-05-13 9:18 ` [Cluster-devel] " Steven Whitehouse 2013-05-13 16:30 ` Randy Dunlap 2013-05-13 16:30 ` [Cluster-devel] " Randy Dunlap [not found] ` <51913F8B.7080201@infradead.org> [not found] ` <51914045.1060900@infradead.org> 2013-05-13 19:45 ` Randy Dunlap 2013-05-13 19:45 ` [Cluster-devel] " Randy Dunlap 2013-05-14 8:51 ` Steven Whitehouse 2013-05-14 8:51 ` [Cluster-devel] " Steven Whitehouse 2013-05-14 17:02 ` [PATCH -next] gfs2: fix DLM depends to fix build errors Randy Dunlap 2013-05-14 17:02 ` [Cluster-devel] " Randy Dunlap 2013-05-15 10:05 ` Steven Whitehouse 2013-05-15 10:05 ` [Cluster-devel] " Steven Whitehouse 2013-05-08 18:26 ` [PATCH -next] media/usb: fix kconfig dependencies (aka bool depending on tristate considered harmful) Randy Dunlap 2013-05-08 21:18 ` Yann E. MORIN 2013-05-08 21:28 ` [PATCH -next v2] " Randy Dunlap
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=518BD826.4040403@infradead.org \ --to=rdunlap@infradead.org \ --cc=cluster-devel@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-next@vger.kernel.org \ --cc=sfr@canb.auug.org.au \ --cc=swhiteho@redhat.com \ --cc=teigland@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.