| Summary: | Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Andy Furniss <adf.lists> |
| Component: | Mesa core | Assignee: | Emil Velikov <emil.l.velikov> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
example patch
make output on bad make output on good |
||
Created attachment 107565 [details]
make output on bad
Created attachment 107566 [details]
make output on good
Here's the diff between the outputs ph4[~]$ diff mesa-build-issue-bad mesa-build-issue-good 1,2c1,3 < bad < a3e9582f09249ad27716ba82c7dfcee685b65d51 --- > Good > > commit bf4aecfb2acc8d0dc815105d2f36eccbc97c284b 200a202 > CXXLD gallium_dri.la 208a211 > CXXLD libvdpau_gallium.la I've run into this as well now, not sure why I didn't seem to before. AFAICT the problem is that the contents of the TARGET_RADEON_WINSYS and TARGET_RADEON_COMMON variables don't end up as dependencies of gallium_dri.la. No idea how to fix it though. :( (In reply to Michel Dänzer from comment #4) > I've run into this as well now, not sure why I didn't seem to before. > > AFAICT the problem is that the contents of the TARGET_RADEON_WINSYS and > TARGET_RADEON_COMMON variables don't end up as dependencies of > gallium_dri.la. No idea how to fix it though. :( Now that is a bit odd. Autohell should automatically add them as deps, considering that they are explicitly mentioned for linking purposes. gallium_dri_la_LIBADD += $(TARGET_LIB_DEPS) \ $(TARGET_RADEON_WINSYS) $(TARGET_RADEON_COMMON) Perhaps it's tripping over the usage of "+=". I'll take a look at it over the next few days. I suspected it might be related to '?=', but that's just a gut feeling. (In reply to Michel Dänzer from comment #6) > I suspected it might be related to '?=', but that's just a gut feeling. Indeed that was the offender. The operator was used as automake tends to just die as soon as it find two "=" operators on the same variable. Yet it seems that it's not the case when the file containing it is 'included', plus the evaluation of the variables was somewhat random - in some cases there were not evaluated by the time the linking it to take place. Not to mention that the libraries were not added to the DEPENDENCIES list. sed 's|?=|=|' does not job with no side effects. commit af897df5083fc94d5a2a011de9894fa1aa852fe2 Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Tue Oct 14 15:25:54 2014 +0100 automake: explicitly set TARGET_RADEON_{WINSYS,COMMON} Originally the variables were set only once via the ?= operator but that causes issues when doing incremental builds. They appear to be undefined and missing from the dependency list despite their addition to LIBADD. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84807 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 107564 [details] example patch Haven't had time to bisect properly, but there are a group of build patches between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b (Good) and a3e9582f09249ad27716ba82c7dfcee685b65d51 (Bad) The issue is that without doing a make distclean applying a trivial patch and doing make no longer works properly. I am radeonsi and from clean build like - ./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= && make -j5 On bad applying a patch and just doing make fails to update lib/gallium/radeonsi_dri.so example patch and output from make on good and bad to be attached.