| Summary: | check-uniq-files target issue | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Jean-pierre Cartal <jpcartal> |
| Component: | Other | Assignee: | Yann E. MORIN <yann.morin.1998> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2018.02.4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
Jean-pierre Cartal
2018-10-19 15:37:39 UTC
Sounds like an excellent idea! The -p option has existed since 2000 so no problem there. Care to send a patch to add it? Here is the patch that I tested on my builds:
diff --git a/package/Makefile.in b/package/Makefile.in
index 58af2ef242..7d3d7c9028 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -216,7 +216,7 @@ TARGET_OBJDUMP = $(TARGET_CROSS)objdump
ifeq ($(BR2_STRIP_strip),y)
STRIP_STRIP_DEBUG := --strip-debug
TARGET_STRIP = $(TARGET_CROSS)strip
-STRIPCMD = $(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note
+STRIPCMD = $(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note -p
else
TARGET_STRIP = /bin/true
STRIPCMD = $(TARGET_STRIP)
BTW, there are also a lot of false positive in staging because of this command :
$(Q)find $(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
$(SED) "s:$(BASE_DIR):@BASE_DIR@:g" \
-e "s:$(STAGING_DIR):@STAGING_DIR@:g" \
$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
-e "s:\(['= ]\)/usr:\\1@STAGING_DIR@/usr:g" \
$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
-e "s:@BASE_DIR@:$(BASE_DIR):g"
Do you think a patch using stat/touch to keep the original modification time of impacted files be interesting ?
The originally reported problem actually only occurs when you do a package-reinstall. Not really the most important use case I'd say. If you do a package rebuild, it works correctly. For the *.la files, the problem indeed occurs, but it already occurs on the first run. Indeed, after every package, we fix up the .la files, and even if they are not really modified, their timestamp is updated. So that really has to be fixed. However, a better fix is to not update all the .la files, but only the .la files really touched by that package. Regarding the original issue, it was not my impression that the bug was only happening on package reinstall. For instance the example I gave with Warning: target file "./usr/lib/libdevmapper-event-lvm2thin.so" was not triggered by a reinstallation of the lvm package if that's what you mean ? As I said, I couldn't reproduce it, so how did you trigger it? You're correct, this is happening when I force a package reinstallation, a full package rebuild does not trigger the issue. However, I think that adding the -p option would still be useful to avoid this issue when reinstalling a package. BTW I created a separate ticket for warnings in staging area (#11416) Hi, Is there any hope for this patch to be added to main buildroot release ? Regards. (In reply to Jean-pierre Cartal from comment #7) We have instead removed the check-uniq-files logic: https://git.buildroot.org/buildroot/commit/?id=2496189a4207173e4cd5bbab90256f911175ee57 |