Closed GoogleCodeExporter closed 9 years ago
Somehow a stray file has ended up in your package install tree. Can you take
post the output of 'ls -la out/build/glibc-compat/install_x86-64_newlib/'?
Original comment by sbc@chromium.org
on 28 Oct 2014 at 4:33
I found the issue:
http://apple.stackexchange.com/questions/14980/why-are-dot-underscore-files-crea
ted-and-how-can-i-avoid-them
Looks like the problem is when you have non-HFS+ filesystems on OSX. What
filesystem to you have BTW? I will have a look at fixing the issue by ignoring
all "._" files.
Original comment by sbc@google.com
on 28 Oct 2014 at 4:35
The following list was the output of 'ls' command executing:
[src] ls -la out/build/glibc-compat/install_x86-64_newlib/
total 8
drwxr-xr-x@ 4 yoichiro staff 136 10 28 18:47 .
drwxr-xr-x@ 6 yoichiro staff 204 10 28 18:47 ..
drwxr-xr-x@ 4 yoichiro staff 136 10 28 18:47 payload
-rw-r--r--@ 1 yoichiro staff 157 10 28 18:47 pkg_info
Original comment by yoichiro...@gmail.com
on 28 Oct 2014 at 10:01
Well, I'm using HFS+ filesystem on my macbook air. Here is the output of the
information by using diskutil:
[src] diskutil info / 7:00:10 ☁ a72bed9
☀
Device Identifier: disk1
Device Node: /dev/disk1
Part of Whole: disk1
Device / Media Name: Macintosh HD
...
File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
Journal: Journal size 24576 KB at offset 0x11502000
Owners: Enabled
Content (IOContent): Apple_HFS
...
Original comment by yoichiro...@gmail.com
on 28 Oct 2014 at 10:08
I think I fixed the problem here:
https://codereview.chromium.org/687823002/
Original comment by sbc@google.com
on 28 Oct 2014 at 10:14
Sorry, I could not fix this issue using the patch. I did the following steps:
1. gclient sync => The patch was applied.
2. head -1523 build_tools/common.sh | tail -8 => Confirm whether the patch was
applied or not
$ head -1523 build_tools/common.sh | tail -8
if [ "${OS_NAME}" = "Darwin" ]; then
# OSX likes to create files starting with ._. We don't want to package
# these.
local args="--exclude ._*"
else
local args=""
fi
LogExecute tar cjf "${PACKAGE_FILE}" -C "${INSTALL_DIR}" ${args} .
3. ./make_all.sh clean => Remove all generated files
4. ./make_all.sh glibc-compat => Do make again
$ ./make_all.sh glibc-compat
+ set -e
+ TARGETS=glibc-compat
+ TARGETS=glibc-compat
+ BUILD_FLAGS=--ignore-disabled
+ export TOOLCHAIN
+ export NACL_ARCH
+ export BUILD_FLAGS
+ NACL_ARCH=x86_64
+ TOOLCHAIN=glibc
+ make glibc-compat
bin/naclports install glibc-compat --ignore-disabled
Building 'glibc-compat' [x86_64/glibc/release]
Build complete 'glibc-compat' [x86_64/glibc/release] [took 0s]
Installing 'glibc-compat' [x86_64/glibc/release]
naclports: invalid file in package: ._pkg_info
make: *** [glibc-compat] Error 1
This issue can be reproduced... Why???
Original comment by yoichiro...@gmail.com
on 29 Oct 2014 at 12:10
[deleted comment]
When I removed my "src" directory of naclports and did from first, I could
build glibc-compat successfully! Thank you for your cooperation!!!
Original comment by yoichiro...@gmail.com
on 29 Oct 2014 at 12:31
Same problem for me (but with openssl) I also needed to do the following
modifications to binary_package.py::152 in order for the installation stage to
work.
152 if name == 'pkg_info':
153 continue
+++ if name.startswith('._'):
+++ continue
154 if not name.startswith(PAYLOAD_DIR + '/'):
155 raise error.PkgFormatError('invalid file in package: %s' % name)
Original comment by nilsknac...@gmail.com
on 17 Jul 2015 at 1:25
We don't want to allow binary packages to contains these extra files. The
correct fix is to not add the to the package in the first place.
Its interesting that these would occur on HFS+ filesystem as it looks like they
should not:
http://apple.stackexchange.com/questions/14980/why-are-dot-underscore-files-crea
ted-and-how-can-i-avoid-them
In any case I can't reproduce this issue, so can someone confirm this change
did not fix the problem: https://codereview.chromium.org/687823002/. If you
can reproduce it can you take a look at why this change didn't fix it?
Original comment by sbc@google.com
on 17 Jul 2015 at 3:08
Original issue reported on code.google.com by
yoichiro...@gmail.com
on 28 Oct 2014 at 1:21