Recent commit below introduced a new library to be linked (libutil.la):
commit 0caf58a6cb82327a3f6a53f05dea8e02f1412a05 Author: Stefan Agner stefan@agner.ch Date: Sat Dec 19 21:52:58 2015 -0800
kmstest: Use util_open()
Use the new util_open() helper instead of open-coding the method for finding a usable device. While at it, make the command-line interface more consistent with that of modetest by adding the -D and -M options.
Signed-off-by: Stefan Agner stefan@agner.ch v2: correctly use util_open() - swap device, module Signed-off-by: Emil Velikov emil.l.velikov@gmail.com
The ordering of the libraries in kmstest_LDADD is causing the following error on my build system:
ld: ../../tests/util/.libs/libutil.a(libutil_la-kms.o): undefined reference to symbol 'drmOpen' ../../.libs/libdrm.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:436: recipe for target 'kmstest' failed make[3]: *** [kmstest] Error 1
The above error is resolved by switching the linking order.
Cc: Stefan Agner stefan@agner.ch Cc: Kristian Høgsberg Kristensen kristian.h.kristensen@intel.com Signed-off-by: Reinette Chatre reinette.chatre@intel.com --- This is a resend since first attempt was made when I was not subscribed to mailing list and it only made it to cc list, not the mailing list.
tests/kmstest/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am index 100662e..9083620 100644 --- a/tests/kmstest/Makefile.am +++ b/tests/kmstest/Makefile.am @@ -18,8 +18,8 @@ kmstest_SOURCES = \
kmstest_LDADD = \ $(top_builddir)/libdrm.la \ - $(top_builddir)/libkms/libkms.la \ - $(top_builddir)/tests/util/libutil.la + $(top_builddir)/tests/util/libutil.la \ + $(top_builddir)/libkms/libkms.la
run: kmstest ./kmstest
Hi Reinette,
[added Emil to CC] Hm, I wonder why that did not happen on my system. What OS/gcc version do you use?
-- Stefan
On 2016-01-27 12:12, Reinette Chatre wrote:
Recent commit below introduced a new library to be linked (libutil.la):
commit 0caf58a6cb82327a3f6a53f05dea8e02f1412a05 Author: Stefan Agner stefan@agner.ch Date: Sat Dec 19 21:52:58 2015 -0800
kmstest: Use util_open() Use the new util_open() helper instead of open-coding the method for finding a usable device. While at it, make the command-line interface more consistent with that of modetest by adding the -D and -M options. Signed-off-by: Stefan Agner <stefan@agner.ch> v2: correctly use util_open() - swap device, module Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>The ordering of the libraries in kmstest_LDADD is causing the following error on my build system:
ld: ../../tests/util/.libs/libutil.a(libutil_la-kms.o): undefined reference to symbol 'drmOpen' ../../.libs/libdrm.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:436: recipe for target 'kmstest' failed make[3]: *** [kmstest] Error 1
The above error is resolved by switching the linking order.
Cc: Stefan Agner stefan@agner.ch Cc: Kristian Høgsberg Kristensen kristian.h.kristensen@intel.com Signed-off-by: Reinette Chatre reinette.chatre@intel.com
This is a resend since first attempt was made when I was not subscribed to mailing list and it only made it to cc list, not the mailing list.
tests/kmstest/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am index 100662e..9083620 100644 --- a/tests/kmstest/Makefile.am +++ b/tests/kmstest/Makefile.am @@ -18,8 +18,8 @@ kmstest_SOURCES = \
kmstest_LDADD = \ $(top_builddir)/libdrm.la \
- $(top_builddir)/libkms/libkms.la \
- $(top_builddir)/tests/util/libutil.la
- $(top_builddir)/tests/util/libutil.la \
- $(top_builddir)/libkms/libkms.la
run: kmstest ./kmstest
Hi Stefan,
On 2016-01-27, Stefan Agner wrote:
[added Emil to CC] Hm, I wonder why that did not happen on my system. What OS/gcc version do you use?
On my host I am building an image using Yocto (http://www.yoctoproject.org/) to contain latest libdrm. In case you are not familiar with Yocto this system will first create its own build environment (think sysroot) and then build this library within it. Since the build environment is separate from host it is very sensitive to dependencies being correct and could explain why this issue is not encountered by folks building on and for their hosts. I have been doing this daily without issue since about April of last year. The version I am using relies on gcc 4.9.2.
Reinette
Hi Reinette,
Thanks for the patch. I've actually made a similar patch one some 12 hours ago. Silly me forgot to push it - it's in master now.
On 27 January 2016 at 21:29, Chatre, Reinette reinette.chatre@intel.com wrote:
Hi Stefan,
On 2016-01-27, Stefan Agner wrote:
[added Emil to CC] Hm, I wonder why that did not happen on my system. What OS/gcc version do you use?
On my host I am building an image using Yocto (http://www.yoctoproject.org/) to contain latest libdrm. In case you are not familiar with Yocto this system will first create its own build environment (think sysroot) and then build this library within it. Since the build environment is separate from host it is very sensitive to dependencies being correct and could explain why this issue is not encountered by folks building on and for their hosts. I have been doing this daily without issue since about April of last year. The version I am using relies on gcc 4.9.2.
Err... sorry I'm not sure how that explains it. The missing symbol has been part of libdrm.so since forever, so regardless which version gets picked (the host one or not) it wouldn't error out in such a way.
I'm leaning that it's due to different LDFLAGS - what are you using ? The first 'offender' that comes to mind is --as-needed although I might be mistaking.
Thanks for the report, it should be working fine now. Emil
Hi Emil,
On 2016-01-27, Emil Velikov wrote:
Hi Reinette,
Thanks for the patch. I've actually made a similar patch one some 12 hours ago. Silly me forgot to push it - it's in master now.
Thank you very much.
On 27 January 2016 at 21:29, Chatre, Reinette reinette.chatre@intel.com wrote:
Hi Stefan,
On 2016-01-27, Stefan Agner wrote:
[added Emil to CC] Hm, I wonder why that did not happen on my system. What OS/gcc version do you use?
On my host I am building an image using Yocto
(http://www.yoctoproject.org/) to contain latest libdrm. In case you are not familiar with Yocto this system will first create its own build environment (think sysroot) and then build this library within it. Since the build environment is separate from host it is very sensitive to dependencies being correct and could explain why this issue is not encountered by folks building on and for their hosts. I have been doing this daily without issue since about April of last year. The version I am using relies on gcc 4.9.2.
Err... sorry I'm not sure how that explains it. The missing symbol has been part of libdrm.so since forever, so regardless which version gets picked (the host one or not) it wouldn't error out in such a way.
I'm leaning that it's due to different LDFLAGS - what are you using ? The first 'offender' that comes to mind is --as-needed although I might be mistaking.
I am indeed using --as-needed
Reinette
dri-devel@lists.freedesktop.org
-
Chatre, Reinette -
Emil Velikov -
Reinette Chatre
-
Stefan Agner