Re: need to build a Windows tar

[Steven Penny]

On Thu, Dec 3, 2009 Mike Maki wrote:

> Where it builds in cygwin but won't run in DOS, the problem now is configure succeeds but make fails in MSYS/MinGW.
>
> rtapelib.c: In function `do_command':
> rtapelib.c:124: error: `SIGPIPE' undeclared (first use in this function)
> rtapelib.c:124: error: (Each undeclared identifier is reported only once
> rtapelib.c:124: error: for each function it appears in.)
> rtapelib.c: In function `rmt_open__':
> rtapelib.c:468: warning: implicit declaration of function `pipe'
> rtapelib.c:477: warning: implicit declaration of function `fork'
> rtapelib.c:500: warning: implicit declaration of function `setuid'
> rtapelib.c:500: warning: implicit declaration of function `getuid'
> rtapelib.c:500: warning: implicit declaration of function `setgid'
> rtapelib.c:500: warning: implicit declaration of function `getgid'
> rtapelib.c: In function `rmt_write__':
> rtapelib.c:602: error: `SIGPIPE' undeclared (first use in this function)

These errors persist after 2 years? Is there no way to build tar for
Windows using MinGW?

[Sergey Poznyakoff-2]

> Is there no way to build tar for Windows using MinGW?

No, you need cygwin for that.

Regards,
Sergey

[Steven Penny]

On Sun, Dec 18, 2011 at 5:51 PM, Sergey Poznyakoff wrote:
>
>> Is there no way to build tar for Windows using MinGW?
>
> No, you need cygwin for that.

Ok so why is MinGW found many times in the "configure" file?

[Paul Eggert]

On 12/18/11 15:55, Steven Penny wrote:
> why is MinGW found many times in the "configure" file?

GNU Tar uses some library code that can run on MinGW, and some
of its configuration creeps into 'configure', but that doesn't
mean that GNU Tar itself runs on MinGW.

It'd be a lot of work to port GNU Tar to MinGW, I expect, and
this is so low priority that it'll probably never get done.
See "Portability between System Types"
<http://www.gnu.org/prep/standards/html_node/System-Portability.html>.

[Sergey Poznyakoff-2]

Steven Penny <svnpenn@...> ha escrit:

> Ok so why is MinGW found many times in the "configure" file?

Actually, it is not:

 tar$ grep -ci mingw configure.ac
 0

Regards,
Sergey

[Joerg Schilling-3]

Paul Eggert <eggert@...> wrote:

> On 12/18/11 15:55, Steven Penny wrote:
> > why is MinGW found many times in the "configure" file?
>
> GNU Tar uses some library code that can run on MinGW, and some
> of its configuration creeps into 'configure', but that doesn't
> mean that GNU Tar itself runs on MinGW.

It seems that stat() on Win-DOS does no deliver inode numbers and as a result
of the fact that the struct stat definition defines ino_t as short make it
impossible to even write a work around for this important standard compliance
bug. Note that MS internally has the important and needed inode number but it
is not forwarded to standard compliant software.

IIRC, recent star versions (see ftp://ftp.berlios.de/pub/schily/) compile on
Win-DOS even with the MS C-Compiler but you will not have nuch luck with it as
the non-compliances introduced by MS make it belive that all files are hard
linked to each other. In any case, mkisofs and sfind definitely compile this way
but the named problems prevent them from being useful.

Things would be simple if MS did minimally follow standards.



Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       joerg.schilling@... (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[Tim Kientzle-2]

On Dec 19, 2011, at 1:31 AM, Joerg Schilling wrote:

> Paul Eggert <eggert@...> wrote:
>
>> On 12/18/11 15:55, Steven Penny wrote:
>>> why is MinGW found many times in the "configure" file?
>>
>> GNU Tar uses some library code that can run on MinGW, and some
>> of its configuration creeps into 'configure', but that doesn't
>> mean that GNU Tar itself runs on MinGW.
>
> It seems that stat() on Win-DOS does no deliver inode numbers and as a result
> of the fact that the struct stat definition defines ino_t as short make it
> impossible to even write a work around for this important standard compliance
> bug. Note that MS internally has the important and needed inode number but it
> is not forwarded to standard compliant software.

With libarchive, we had to use Windows-specific code to
work around this.  Fortunately, it only affected a couple
of places (the parts of libarchive that actually deal
with disk attributes are pretty well isolated).

Cheers,

Tim

[Joerg Schilling-3]

Tim Kientzle <tim@...> wrote:

> > It seems that stat() on Win-DOS does no deliver inode numbers and as a result
> > of the fact that the struct stat definition defines ino_t as short make it
> > impossible to even write a work around for this important standard compliance
> > bug. Note that MS internally has the important and needed inode number but it
> > is not forwarded to standard compliant software.
>
>
> With libarchive, we had to use Windows-specific code to
> work around this.  Fortunately, it only affected a couple
> of places (the parts of libarchive that actually deal
> with disk attributes are pretty well isolated).

Star has this clean separation since February 1985 when I ported star from UNOS
to UNIX. Nowadays, libfind is pretty tight written around struct stat and
libfind fives a lot of interesting features to star and mkisofs.

But when you have been able to work around the problem, I should be able to do
the same.


I did already write a readdir() amulation with Win-DOS specific code....

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       joerg.schilling@... (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily