Bug 849 - "customize" package copies files to wrong place in target tree
Summary: "customize" package copies files to wrong place in target tree
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 normal
Target Milestone: 2010.05
Assignee: unassigned
URL:
Keywords:
: 1135 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-08 18:43 UTC by Grant Edwards
Modified: 2010-05-06 21:29 UTC (History)
3 users (show)

See Also:
Host: Gentoo Linux
Target: Atmel at91sam9g20
Build:


Attachments
Patch to fix bug that copies files to wrong place in target tree (1.01 KB, patch)
2010-01-08 18:43 UTC, Grant Edwards
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Grant Edwards 2010-01-08 18:43:36 UTC
Created attachment 885 [details]
Patch to fix bug that copies files to wrong place in target tree

I'm attempting to use the "customize" package to get
libgcc_s.so files into my target filesystem, and it doesn't
seem to work.  I put files into the package like so:

   $ tree customize
   customize
   |-- Config.in
   |-- customize.mk
   `-- source
       |-- asdf
       `-- lib
           |-- foobar
           |-- libgcc.a
           |-- libgcc_eh.a
           |-- libgcc_s.so
           `-- libgcc_s.so.1

But what ends up on my target filesystem is

  /asdf
  /lib/lib/libgcc_s.so
  /lib/lib/libgcc_s.so.1
  /lib/lib/foobar

The two .a files end up being removed later in the build
process, but the other files that I expect to find in /lib end
up in /lib/lib.  The mislocation appears to be due to a bug in
customize.mk:

     1  #############################################################
     2  #
     3  # Any custom stuff you feel like doing....
     4  #
     5  #############################################################
     6  CUST_DIR:=package/customize/source
     7
     8  $(BUILD_DIR)/.customize:
     9          rm -f $(BUILD_DIR)/series
    10          (cd $(CUST_DIR); \
    11           /bin/ls -d * > $(BUILD_DIR)/series || \
    12           touch $(BUILD_DIR)/series )
    13          for f in `cat $(BUILD_DIR)/series`; do \
    14                  cp -af $(CUST_DIR)/$$f $(TARGET_DIR)/$$f; \
    15          done
    16          rm -f $(BUILD_DIR)/series
    17          touch $@

Line 14 doesn't work right if there are any pre-existing
directories in the target directory.  In my case it ends up
doing:
   
   cp -af package/custom/source/lib output/target/lib
       
That results in files ending up in /lib/lib instead of /lib
           
Shouldn't line 14 specify the bare target_dir (and not
specify a target filename)?  Copy a file will still work the
same (since the destination is known to be a directory), and
now copying a directory will work when it didn't used to:

    14                  cp -af $(CUST_DIR)/$$f $(TARGET_DIR)/; \
Comment 1 Paulius Zaleckas 2010-03-12 17:43:31 UTC
Wrong. Then it will copy wrongly files that needs new directory to be created.
I think we should use install instead of cp.
Comment 2 Grant Edwards 2010-03-12 18:21:03 UTC
(In reply to comment #1)

> Wrong. Then it will copy wrongly files that needs new directory to be
> created. I think we should use install instead of cp.

Can you provide an example where it fails?

I tested the patch pretty extensively and it worked fine for me - when
new directories needed to be created.




Comment 3 Thomas Petazzoni 2010-04-09 14:55:00 UTC
*** Bug 1135 has been marked as a duplicate of this bug. ***
Comment 4 Peter Korsgaard 2010-05-06 21:29:00 UTC
Fixed in git (ea0695ff5ed) - Thanks, and sorry for the slow response.