| Summary: | can't find the daemon/failure/warning... functions needed by lsb. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | niqingliang2003 <niqingliang2003> | ||||
| Component: | core | Assignee: | Kai Kang <kai.kang> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | kai.kang, liang.li2, meta.mr.watcher, meta.watcher, niqingliang2003, song.liu, Xiaofeng.yan, zhenfeng.zhao | ||||
| Version: | 1.2 | ||||||
| Target Milestone: | 1.3 M2 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | (QA testing completed) Done | ||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | --- | |||||
| Attachments: |
|
||||||
|
Description
niqingliang2003
2012-03-16 08:33:00 UTC
Hi qingliang, these missing functions in file functions cause failures. but LSB Test Suite for 4.1 can't report this error. So LSB Test Suite could not use this command. Can you tell me what command call lsb_start_daemon in your program. I'm invesigating opensaf, and opensaf will use lsb functions. when start opensaf service, it called lsb scripts, and lsb scripts report missing functions. (In reply to comment #1) > Hi qingliang, > > these missing functions in file functions cause failures. but LSB Test Suite > for 4.1 can't report this error. So LSB Test Suite could not use this command. > Can you tell me what command call lsb_start_daemon in your program. I will add these missing functions. and for complying error, I need investigate this. I will add these missing functions. and for compiling error, I need to investigate this for the compiling error, I found it used the /usr/lib/libxx on host rootfs, but it should use <sysroot_in_build_dir>/usr/lib/libxx. (In reply to comment #4) > I will add these missing functions. and for compiling error, I need to > investigate this for the compiling problem, I compiled core-image-lsb successfully. So I think Mark Halt answered your question about compiling error on your side. I don't think so. I do a clean building with the same error. I have not touched the specific glibc version. as I said, the do_compile should use the libXrandr in build_sysroot directory, but it used it in host system. and I have checked that, there IS the lib in build_sysroot directory. you can build it successfully, only because your host's lib is using glibc 2.13, but I'm using archlinux, all package is the newest. the gconf used host's libXrandr, but want check its dependency in build_sysroot, that the reason. (In reply to comment #6) > for the compiling problem, I compiled core-image-lsb successfully. So I think > Mark Halt answered your question about compiling error on your side. do you used the same arch of your host? my host is x86-64, so I used qemux86-64. and maybe you can change the content of libXrandr on your host to another one, to test if it try to check it. PS: Indeed, some problem can only be found on archlinux:) (In reply to comment #6) > for the compiling problem, I compiled core-image-lsb successfully. So I think > Mark Halt answered your question about compiling error on your side. do you received the email I have sended to oe-core about the compile error?
maybe the problem is located in 'ld'
with both sysroot and rpath(/usr/lib/../lib), the ld will search the implicit depended lib in host's rootfs first.
indeed, it should search in sysroot first.
following bug('s fix) may help:
http://sourceware.org/bugzilla/show_bug.cgi?id=10340
(In reply to comment #6)
> for the compiling problem, I compiled core-image-lsb successfully. So I think
> Mark Halt answered your question about compiling error on your side.
the only thing I doubt is: the cross compiling still has this kind of problems. the CLFS exist 2.x years. and found the ld's search rule is so sophisticated. in the ld cmd generated by libtool, the xx.so is auto prefixed by $sysroot, but the rpath not. without rpath or with rpath prefixed by $sysroot, both can compiled successfully. one patch for binutils is for auto clear the $sysroot prefix in the finally binary, so maybe a workaround is add $sysroot on rpath just like other .so. what is the progress of it? Created attachment 410 [details]
file functions from initscripts-9.03.
Replace /etc/init.d/functions with this file. Report results when having problem, Please. Thanks
further suggestion: according redhat/debian, maybe we should add lsb-core/lsb-graphics/lsb-xxx package, indeed, there is no content in them, but only the RDEPENDS. (In reply to comment #13) > Created attachment 410 [details] > file functions from initscripts-9.03. > > Replace /etc/init.d/functions with this file. Report results when having > problem, Please. Thanks Hi qingliang, Do you have any problem after running functions in attachment. Can it pass your test? Thanks Yan http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9205cba286e54576f95a5894d3953dcda43cf8bf http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6e416742ff131265a2471423bf5bf47e2fc4df3e http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d32f9004f81d05c94f92a980285a70f49d9b3919 build qemux86-64 arch core-image-lsb, there are no errors in build process,but when boot up the lsb image ,two seperated files found in /etc/init.d: functions functions.lsbinitscripts daemon, failure, warning functions are found in file "functions.lsbinitscripts",not in file "functions". by the bug's description information,reopen it. git info:60543b931d073e17ad935aacfbd0d4eba76e2360 git branch: poky/master test env : host : ubuntu 11.10 x86_64 commit to Yocto commit 7890697c8f59fad5878d5ecd644db4dbff6034f6 verified on : git info: eb0cb7e8234f5d2e5623406e9660be91cf52f65e git branch: poky/master run "ls -l" in "/etc/init.d" dir of the lsb image,"functions" now is the symbol link to "functions.lsbinitscripts". lrwxrwxrwx 1 root root 24 Jul 17 19:02 functions -> functions.lsbinitscripts |