Re: /usr/bin/tar creates invalid lib file
26.03.2012 03:25, Tim Kientzle пишет: On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: On (25/03/2012 10:53), Tim Kientzle wrote: On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). Ugh. I'll probably need your help to diagnose this more precisely. Here is the root problem: tar thinks this is a sparse file with nothing in it.On FreeBSD, bsdtar now uses lseek(SEEK_HOLE) to identify holes in the file. For some reason, bsdtar is storing this file as just one big hole. I experience a related issue. lseek(SEEK_HOLE) error checks are too strict. Files are not added to archive if lseek(SEEK_HOLE) fails. Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. This has already been fixed upstream. I'll get the fix merged soon… Boris: What filesystem are you using? zfs -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On 26.03.2012 15:36, Andriy Gapon wrote: on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) I may misunderstand the PR but it seems to me that the discussion was about amd64. Other than that looks familiar. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
on 26/03/2012 15:01 Boris Samorodov said the following: On 26.03.2012 15:36, Andriy Gapon wrote: on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) I may misunderstand the PR but it seems to me that the discussion was about amd64. Other than that looks familiar. My impression is that the PR compared FreeBSD pre-ZFSv28 and ZFSv28 behavior, i386 vs amd64 seems to be a bit of noise in the signal. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On Mar 26, 2012, at 1:42 AM, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ? Yes, that could definitely be related. It will take me a day or two to get a fix into libarchive. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: On 24.03.2012 01:29, Dimitry Andric wrote: On 2012-03-23 21:12, Boris Samorodov wrote: I'm not sure but it seems to me that the question is more about -current that -ports. While updating devel/nspr I get this: ... /usr/bin/strip: /usr/local/lib/libnspr4.so.1: File format not recognized It builds and installs fine here, both on i386 and amd64, using both gcc and clang. What is the output of: file /usr/local/lib/libnspr4.so.1 on your system? I've done some steps to diagnose the case. Seems that /usr/bin/tar does not create correct library: - % file /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped % file /usr/local/lib/libnspr4.so.1 /usr/local/lib/libnspr4.so.1: data % hd -C /usr/local/lib/libnspr4.so.1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * % tar --version bsdtar 3.0.3 - libarchive 3.0.3 - The library (/usr/local/lib/libnspr4.so.1) is created by the command: - /usr/bin/tar -C /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib --dereference -cf - . | /usr/bin/tar -C /usr/local/lib -xof - - Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve test.tar Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). Ugh. I'll probably need your help to diagnose this more precisely. Here is the root problem: tar thinks this is a sparse file with nothing in it.On FreeBSD, bsdtar now uses lseek(SEEK_HOLE) to identify holes in the file. For some reason, bsdtar is storing this file as just one big hole. There are a lot of things here that don't make sense: * The extracted file should be all zero bytes. (The 2.0.0.241971.0. is the sparse file map, it's not really part of the file.) How are you extracting this? * Can you run the tar command under truss or ktrace and look for calls to lseek()? That would help verify that this is really a tar bug and not a filesystem or kernel bug. I'll spend some time today to see if I can reproduce the problem here. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
25.03.2012 21:53, Tim Kientzle пишет: On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). Ugh. I'll probably need your help to diagnose this more precisely. Here is the root problem: tar thinks this is a sparse file with nothing in it.On FreeBSD, bsdtar now uses lseek(SEEK_HOLE) to identify holes in the file. For some reason, bsdtar is storing this file as just one big hole. There are a lot of things here that don't make sense: * The extracted file should be all zero bytes. (The 2.0.0.241971.0. is the sparse file map, it's not really part of the file.) How are you extracting this? I used misc/mc to walk through the filesystem of the tar archive and then just copy F5 the library to an existing file system. OK, you are right. Seems that mc has made a joke on me. When I extract the file at command line it consists of zeros: - % tar xvf /tmp/test.tar --strip-components 16 % ls -l total 1 -rwxr-xr-x 1 bsam wheel 241971 24 мар 08:48 libnspr4.so.1 % hd libnspr4.so.1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0003b130 - * Can you run the tar command under truss or ktrace and look for calls to lseek()? That would help verify that this is really a tar bug and not a filesystem or kernel bug. Interesting... I'll create three tar archives (without truss, with truss and with kdump): - % ls -l /tmp/test/ total 0 % sudo tar -cvf /tmp/test/no-truss.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 [...] % sudo truss tar -cvf /tmp/test/truss.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 [...] % sudo ktrace tar -cvf /tmp/test/ktrace.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 % ls -l /tmp/test total 248 -rw-r--r-- 1 root wheel3072 25 мар 22:47 ktrace.tar -rw-r--r-- 1 root wheel3072 25 мар 22:46 no-truss.tar -rw-r--r-- 1 root wheel 243712 25 мар 22:47 truss.tar - Seems that we get a good tar archive while using truss! Lets see what kdump says. The relevant last part is attached. I'll spend some time today to see if I can reproduce the problem here. Thanks. Let me know if I can help you here. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve 4379 bsdtar GIO fd 5 read 537 bytes # $FreeBSD: head/etc/group 218046 2011-01-28 22:28:12Z pjd $ # wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: operator:*:5:root,bsam 4379 bsdtar RET read 537/0x219 4379 bsdtar CALL close(0x5) 4379 bsdtar RET close 0 4379 bsdtar CALL madvise(0x3414f000,0x8000,MADV_FREE) 4379 bsdtar RET madvise 0 4379 bsdtar CALL __acl_get_link(0x34016100,ACL_TYPE_ACCESS,0x34148000) 4379 bsdtar NAMI /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 4379 bsdtar RET __acl_get_link -1 errno 22 Invalid argument 4379 bsdtar CALL extattr_list_link(0x34016100,0x1,0,0) 4379 bsdtar NAMI /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 4379 bsdtar RET extattr_list_link 0 4379 bsdtar CALL pathconf(0x34016100,0x15) 4379 bsdtar NAMI /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 4379 bsdtar RET pathconf 512/0x200 4379 bsdtar CALL open(0x34016100,0x4O_NONBLOCK,unused0) 4379 bsdtar NAMI /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 4379 bsdtar RET open 5 4379 bsdtar CALL lseek(0x5,0,SEEK_SET,0x3) 4379 bsdtar RET lseek 0 4379 bsdtar CALL lseek(0x5,0,SEEK_SET,0x4) 4379 bsdtar RET lseek 0 4379 bsdtar CALL lseek(0x5,0,SEEK_SET,0x3) 4379 bsdtar RET lseek -1 errno 6 Device not configured 4379 bsdtar CALL close(0x5) 4379 bsdtar RET close 0 4379 bsdtar CALL write(0x2,0x82bfe438,0x5) 4379 bsdtar GIO fd 2 wrote 5 bytes tar: 4379 bsdtar RET
Re: /usr/bin/tar creates invalid lib file
On (25/03/2012 10:53), Tim Kientzle wrote:
On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote:
On 24.03.2012 21:00, Tim Kientzle wrote:
On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote:
Can you send me the output of:
tar -cvf /tmp/test.tar
/usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
(A tar archive containing only that one source file.)
This looks similar to a bug that we found in libarchive recently
I didn't think that bug impacted FreeBSD, but I may have been
wrong…. if it did, it will be obvious from the structure of the
created archive.
The following file is extracted after tarring:
-
% hd libnspr4.so.1
32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00
|2.0.0.241971.0..|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
*
0200
-
The tar file itself attached (3KB in length).
Ugh. I'll probably need your help to diagnose this more precisely.
Here is the root problem: tar thinks this is a sparse file
with nothing in it.On FreeBSD, bsdtar now uses
lseek(SEEK_HOLE) to identify holes in the file. For
some reason, bsdtar is storing this file as just one big hole.
I experience a related issue. lseek(SEEK_HOLE) error checks are too
strict. Files are not added to archive if lseek(SEEK_HOLE) fails.
Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable.
I run stacked file system (PEFS) on top of ZFS. ZFS reports
_PC_MIN_HOLE_SIZE, but ioctls to lower level fs disabled are in PEFS.
I work around it by properly handling _PC_MIN_HOLE_SIZE.
Test case:
% for i in a b c; do echo $i $i; done
% tar cf 1.tar a b c
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
% ls -l 1.tar
-rw-r--r-- 1 gleb gleb 1024 Mar 26 00:28 1.tar
% tar tf 1.tar # -- no files in archive
%
truss log:
__acl_get_link(0x801c8c100,0x2,0x801d82000,0x0,0x1000,0x0) ERR#22 'Invalid
argument'
extattr_list_link(0x801c8c100,0x1,0x0,0x0,0x7fffc530,0x0) ERR#45 'Operation
not supported'
pathconf(a,0x15) = 512 (0x200)
open(a,O_NONBLOCK,03751270)= 5 (0x5)
lseek(5,0x0,0x3) ERR#25 'Inappropriate ioctl
for device'
close(5) = 0 (0x0)
tar: write(2,tar: ,5) = 5 (0x5)
Thanks,
Gleb.
There are a lot of things here that don't make sense:
* The extracted file should be all zero bytes. (The 2.0.0.241971.0. is the
sparse file map, it's not really part of the file.) How are you extracting
this?
* Can you run the tar command under truss or ktrace and look for calls to
lseek()? That would help verify that this is really a tar bug and not a
filesystem or kernel bug.
I'll spend some time today to see if I can reproduce the problem here.
Tim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: On (25/03/2012 10:53), Tim Kientzle wrote: On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). Ugh. I'll probably need your help to diagnose this more precisely. Here is the root problem: tar thinks this is a sparse file with nothing in it.On FreeBSD, bsdtar now uses lseek(SEEK_HOLE) to identify holes in the file. For some reason, bsdtar is storing this file as just one big hole. I experience a related issue. lseek(SEEK_HOLE) error checks are too strict. Files are not added to archive if lseek(SEEK_HOLE) fails. Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. This has already been fixed upstream. I'll get the fix merged soon… Boris: What filesystem are you using? Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: I experience a related issue. lseek(SEEK_HOLE) error checks are too strict. Files are not added to archive if lseek(SEEK_HOLE) fails. Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. Just noticed that lseek(1) doesn't document ENOTTY as a valid response code. Should it? Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
On Sun, Mar 25, 2012 at 04:32:53PM -0700, Tim Kientzle wrote: On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: I experience a related issue. lseek(SEEK_HOLE) error checks are too strict. Files are not added to archive if lseek(SEEK_HOLE) fails. Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. Just noticed that lseek(1) doesn't document ENOTTY as a valid response code. Should it? It seems that man page contradicts the actual lseek(2) behaviour. Man page states that there shall be a virtual hole after file end, even on the filesystems not supporting hole reports. Is there some regression test set for SEEK_HOLE/SEEK_DATA ? I found nothing in our tests, in particular, pjdfstest does not mention the options. pgpl9f9v1S9L3.pgp Description: PGP signature
Re: /usr/bin/tar creates invalid lib file (was: Re: /usr/bin/strip: File format not recognized)
On Fri, Mar 23, 2012 at 9:51 PM, Boris Samorodov b...@passap.ru wrote: On 24.03.2012 01:29, Dimitry Andric wrote: On 2012-03-23 21:12, Boris Samorodov wrote: I'm not sure but it seems to me that the question is more about -current that -ports. While updating devel/nspr I get this: ... /usr/bin/strip: /usr/local/lib/libnspr4.so.1: File format not recognized It builds and installs fine here, both on i386 and amd64, using both gcc and clang. What is the output of: file /usr/local/lib/libnspr4.so.1 on your system? I've done some steps to diagnose the case. Seems that /usr/bin/tar does not create correct library: - % file /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped % file /usr/local/lib/libnspr4.so.1 /usr/local/lib/libnspr4.so.1: data % hd -C /usr/local/lib/libnspr4.so.1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * % tar --version bsdtar 3.0.3 - libarchive 3.0.3 - The library (/usr/local/lib/libnspr4.so.1) is created by the command: - /usr/bin/tar -C /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib --dereference -cf - . | /usr/bin/tar -C /usr/local/lib -xof - All that does is shuffle around files; it doesn't make any libraries. The question I'd have is are there multiple instances running in parallel, or not? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file (was: Re: /usr/bin/strip: File format not recognized)
On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: On 24.03.2012 01:29, Dimitry Andric wrote: On 2012-03-23 21:12, Boris Samorodov wrote: I'm not sure but it seems to me that the question is more about -current that -ports. While updating devel/nspr I get this: ... /usr/bin/strip: /usr/local/lib/libnspr4.so.1: File format not recognized It builds and installs fine here, both on i386 and amd64, using both gcc and clang. What is the output of: file /usr/local/lib/libnspr4.so.1 on your system? I've done some steps to diagnose the case. Seems that /usr/bin/tar does not create correct library: - % file /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped % file /usr/local/lib/libnspr4.so.1 /usr/local/lib/libnspr4.so.1: data % hd -C /usr/local/lib/libnspr4.so.1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * % tar --version bsdtar 3.0.3 - libarchive 3.0.3 - The library (/usr/local/lib/libnspr4.so.1) is created by the command: - /usr/bin/tar -C /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib --dereference -cf - . | /usr/bin/tar -C /usr/local/lib -xof - - Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
24.03.2012 19:04, Garrett Cooper пишет: On Fri, Mar 23, 2012 at 9:51 PM, Boris Samorodov b...@passap.ru wrote: On 24.03.2012 01:29, Dimitry Andric wrote: On 2012-03-23 21:12, Boris Samorodov wrote: I'm not sure but it seems to me that the question is more about -current that -ports. While updating devel/nspr I get this: ... /usr/bin/strip: /usr/local/lib/libnspr4.so.1: File format not recognized It builds and installs fine here, both on i386 and amd64, using both gcc and clang. What is the output of: file /usr/local/lib/libnspr4.so.1 on your system? I've done some steps to diagnose the case. Seems that /usr/bin/tar does not create correct library: - % file /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped % file /usr/local/lib/libnspr4.so.1 /usr/local/lib/libnspr4.so.1: data % hd -C /usr/local/lib/libnspr4.so.1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * % tar --version bsdtar 3.0.3 - libarchive 3.0.3 - The library (/usr/local/lib/libnspr4.so.1) is created by the command: - /usr/bin/tar -C /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib --dereference -cf - . | /usr/bin/tar -C /usr/local/lib -xof - All that does is shuffle around files; it doesn't make any libraries. The question I'd have is are there multiple instances running in parallel, or not? Since I tried the command by hand and got the same result as while using the port, I assume that the answer is no, there are not. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/tar creates invalid lib file
24.03.2012 21:00, Tim Kientzle пишет: Can you send me the output of: Sure. I'll do it tomorrow (the machine is at work). -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
