https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2662 Lustre <p>I have recreated the issue here:<br/> <a href="http://review.whamcloud.com/5142" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5142</a></p> <p>Basically it started when strlcpy was being used in lustre/utils/liblustreapi.c. </p> <p>For some fun reason we get</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>... gcc -g -Wall -fPIC -D_GNU_SOURCE -g -O2 -Werror -o ll_dirstripe_verify ll_dirstripe_verify.o -L../../lustre/utils -llustreapi ../../libcfs/libcfs/libcfs.a ../../libcfs/libcfs/libcfs.a(libcfs_a-user-prim.o): In function `cfs_create_thread': /home/build/lustre-release/libcfs/libcfs/user-prim.c:241: undefined reference to `pthread_create' ... </pre> </div></div> <p>If you drop the small change out the system builds fine. </p> a patch pushed via git. LU-2662

Build: pthread build issue

Bug Major Resolved Fixed Minh Diep Keith Mannthey Mon, 21 Jan 2013 22:20:28 +0000 Tue, 15 Oct 2013 22:07:48 +0000 Wed, 24 Jul 2013 22:27:08 +0000 Lustre 2.4.0 Lustre 2.4.0 Lustre 2.5.0 0 5 <p>Keith, what is the original source of this problem? I don't see strlcpy() being used in liblustreapi.c anywhere.</p> <p>I can see the build failures in your patch, but we already use strlcpy() in a couple of places in the code without problems. The compile error in <a href="http://review.whamcloud.com/5142" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5142</a> is different than what is posted above:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Making all in mpi ../../../lustre/utils/liblustreapi.so: undefined reference to `strlcpy' collect2: ld returned 1 exit status </pre> </div></div> <p>yet we do use strlcpy() successfully in cfs_get_environ() and class_set_global() for the jobid code.</p> <p>Sorry the build test was just an example of a change Bull is wanting. I had linked to build to this LU but I didn't check to see the fails were the same. </p> <p>I get the pthread issue in my local RHEL6.3 build environment without this strlcpy one. Bull sees this same issue as well, they are the ones who found it. Some complicated string handling code was submitted in a patch where strlcpy could have been used and it brought this issue out.</p> <p>The test patch is just an example of the usage Bull would like to do, it is not real code and it seems to break the build (but not on RHEL5). </p> <p>I wonder why my local build environment is different the the auto build server.</p> <p>From my local build:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>cc -g -Wall -fPIC -D_GNU_SOURCE -g -O2 -Werror -o ll_dirstripe_verify ll_dirstripe_verify.o -L../../lustre/utils -llustreapi ../../libcfs/libcfs/libcfs.a ../../libcfs/libcfs/libcfs.a(libcfs_a-user-prim.o): In function `cfs_create_thread': /home/build/lustre-release/libcfs/libcfs/user-prim.c:241: undefined reference to `pthread_create' collect2: ld returned 1 exit status </pre> </div></div> <p>We get the error when trying to build libcfs.a </p> <p>The autobuild may have failed because there is no generally usable strlcpy</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>checking for strlcpy... no </pre> </div></div> <p>I don't have one either but it seems the environment is different. </p> <p>The non-glibc version of strlcpy is in user-prim.c I am not quite sure how RHEL5 worked without including libcfs/user_prim.h but I added it to the test build to see if the pthread will show itself in the build system. </p> <p>For reference adding include libcfs/user-prim.h did not change the pthread issue on my local build. </p> <p>I diffed a good build and a bad build and I really don't see anything that stands out. Same flags and same files are being used. </p> <p>I am going to look into this more tomorrow. </p> <p>The real build that fails <a href="http://build.whamcloud.com/job/lustre-reviews/12561/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/12561/</a></p> <p>The adding the libcfs/user-prim.h moved along our build system</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>... Making all in mpi ../../../lustre/utils/liblustreapi.so: undefined reference to `strlcpy' collect2: ld returned 1 exit status make[4]: *** [cascading_rw] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.AU4Ljc (%build) ... </pre> </div></div> <p>Ok so I know a little more. </p> <p>The non-glibc strlxxx code resides in libcfs_a-user-prim. It seems as are putting together liblustreapi we link in libcfs_a-user-prim.o (which requires pthread). </p> <p>It seems we maybe able to add -pthread to liblustreapi in this case. I continue to look into this. </p> <p>It seems we need add the pthread libs to the test directory makefile for a few files. </p> <p><a href="http://review.whamcloud.com/5180" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5180</a></p> <p>I am able to build locally with these changes. I am not sure how the build system will react. </p> <p>I resubmitted the build test <a href="http://review.whamcloud.com/5142" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5142</a> with a dependency on the makefile change. </p> <p>Current Status:</p> <p><a href="http://review.whamcloud.com/5180" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5180</a> allows me to build local but does not allow the build system to work. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>lustre/tests/Makefile.am:1: `:='-style assignments are not portable lustre/tests/Makefile.am:81: `:='-style assignments are not portable </pre> </div></div> <p>is seen in the build system and my local setup. Investigating further.</p> <p>I submitted another set of changes. I converted the ':=' to "=". I don't get warnings on my local system with this but I am not sure it will help the build environment. </p> <p>Well local build is till working at build system is still failing on on the unknown strlcpy. Spent some more time today looking at this and I don't quite see the next thing to try. </p> <p>Keith, the ":=" warnings are spurious. Please start with <a href="http://review.whamcloud.com/3714" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3714</a> if you want to clean that up. That patch doesn't build for some reason, and I haven't had time to look into the details.</p> <p>I think the root of the problem is mostly unrelated to strlcpy() itself, but instead the <tt>cfs_create_thread()</tt> function (also declared in user-prim.h) is the cause of the pthread dependency, which is only defined if HAVE_LIBPTHREAD is true. This is causing the <tt>libcfs/libcfs/user-prim.c</tt> file to reference pthread functions, but they are completely unnecessary for liblustreapi.</p> <p>Somehow, HAVE_LIBPTHREAD is being enabled, and by virtue of some change having added user-prim.h to get access to strlcpy() it is also dragging in the cfs_create_thread() code. Not sure on the details, but hopefully this helps you.</p> <p><a href="http://review.whamcloud.com/5180" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5180</a> allows me to build locally. </p> <p> Using in the strlxxx functions brings in the user-prim.h code that needs pthread support into liblustreapi. I added PTHREAD_LIBS in two spots. "$(LIBLUSTREAPI) $(PTHREAD_LIBS)" this allows me to build locally </p> <p>The confusing part is the build system (<a href="http://review.whamcloud.com/5142" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5142</a>) still fails with name resolution for the strlxx function. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Making all in mpi ../../../lustre/utils/liblustreapi.so: undefined reference to `strlcpy' collect2: ld returned 1 exit status make[4]: *** [cascading_rw] Error 1 </pre> </div></div> <p>Locally building and the build system are behaving differently. I am a little stuck with this. </p> <p>I am told I need to look into "lbuild". </p> <p>Peter mentioned you were the right person to look at this. </p> <p>Is there a outlook for this issue? </p> <p>I don't have the bandwidth to look into this right now.</p> <p>hmm...I built using lbuild and did not hit the failure on latest kernel. let me rebase the patch and try again</p> <p>Minh can you submit a job to the build system? That is where the issue has been seen, it was thought to be a general lbuild issue, but perhaps it is more specific to the build system. </p> <p><a href="http://review.whamcloud.com/4154" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4154</a></p> <p>From a month or so ago still fails to build:<br/> <a href="http://build.whamcloud.com/job/lustre-reviews/14514/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/14514/</a></p> <p>passed the build system: <a href="http://build.whamcloud.com/job/lustre-reviews/15362/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/15362/</a></p> <p>Well perhaps the build system has changed enough it now works with <a href="http://build.whamcloud.com/job/lustre-reviews/15362/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/15362/</a> or without the patch? </p> <p>Andreas,</p> <p>Should we proceed to review and land this patch <a href="http://review.whamcloud.com/5180" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5180</a> ?</p> <p>If that patch isn't strictly needed to build, I would rather abandon it. It adds pthread libraries to tools that shouldn't otherwise need them, so if the problem is gone then I'm happy to abandon this patch. It looks to me like there was some inconsistency between HAVE_LIBPTHREAD being defined in one place and not another, so it isn't surprising that some build changes cleaned it up.</p> <p>I resubmitted the patch for <a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a> to see if the issue without the patch still occurs.</p> <p><a href="http://review.whamcloud.com/4154" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4154</a> </p> <p>The build from last night failed with the issue, some sort of a fix to Master is needed. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>./libptlctl.a(debug.o): In function `jt_dbg_debug_kernel': /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.3.65/lnet/utils/debug.c:605: undefined reference to `strlcpy' ../../libcfs/libcfs/libcfsutil.a(libcfsutil_a-parser.o): In function `Parser_help': /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.3.65/libcfs/libcfs/util/parser.c:463: undefined reference to `strlcat' collect2: ld returned 1 exit status make[3]: *** [debugctl] Error 1 make[3]: *** Waiting for unfinished jobs.... ../../libcfs/libcfs/libcfs.a(libcfs_a-user-prim.o): In function `cfs_create_thread': /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.3.65/libcfs/libcfs/user-prim.c:241: undefined reference to `pthread_create' </pre> </div></div> <p>Keith, are we working on this bug or <a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a>. Can we close this one and focus on the other?</p> <p>This issue tracks the build issue with the Patch from 2074. I think the context is here for dealing with the build system issue and I would rather not close this issue until the patch for <a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a> can build.</p> <p><a href="http://review.whamcloud.com/5180" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5180</a> is needed to Build the patch for <a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a>. </p> <p>Well that didn't work... </p> <p><a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a> was submitted right after this patch was merged but it didn't fix lbuild. <a href="http://build.whamcloud.com/job/lustre-reviews/16287/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/16287/</a></p> <p>the patch for this ticket has landed on master and a solution has been provided for <a href="https://jira.whamcloud.com/browse/LU-2074" title="Fix &#39;copy into fixed size buffer&#39; errors" class="issue-link" data-issue-key="LU-2074"><del>LU-2074</del></a>. This is no longe a blocker for that. closing</p> Development Rank 1|hzvfu7: Rank (Obsolete) 6212 Severity