build fails on SCO 5

[GoogleCodeExporter]

libarchive/archive.h defines some types appropriate to the platform, but those 
types aren't used elsewhere in the code. There are many direct uses of, e.g., 
uint32_t.

The attached patch against trunk is big, but it just rearranges some stuff in 
archive.h, archive_entry.h, and archive_platform.h, and then seds the C99 types 
in libarchive/* to use the internal names.

Thank you.

Original issue reported on code.google.com by brianchi...@gmail.com on 18 Jan 2011 at 6:34

Attachments:

• types.patch

[GoogleCodeExporter]

I'm curious:   What platform have you encountered that lacks both stdint.h and 
inttypes.h?

Original comment by kientzle@gmail.com on 19 Jan 2011 at 6:29

[GoogleCodeExporter]

I'm sad to say that the box where I encountered the problem runs SCO 5.

Original comment by brianchi...@gmail.com on 19 Jan 2011 at 3:37

[GoogleCodeExporter]

I suspect we can address your problems without requiring anything quite this 
dramatic.  If you can give us some more details (such as the exact compiler 
errors) that prompted this, I think we can help you out.

There is already some logic in the configure scripts to define int64_t and a 
few other C99-style types if they're not provided by the local system.  Can we 
extend that logic to cover the cases you've found?

Older Unix dialects used type names of the form u_int32_t or __int32_t, 
typically defined in sys/types.h.  Are those available on your system?  If so, 
we might use that to extend the existing configuration logic.

My biggest concern about this as written is the addition of so many new types 
to archive.h.  These types aren't used by any public libarchive interface and 
should not be exposed to libarchive users.

Original comment by kientzle@gmail.com on 20 Jan 2011 at 6:02

[GoogleCodeExporter]

I'm assuming the point of confusion is the purpose of the existence of 
__LA_INT64_T if the requirement is that these types not be used.  For 
consistency, it makes sense for the public prototype to match the 
implementation which is what this patch appears to do as the assumption was 
those datatypes are supported.  Obviously an end-user may not have defined 
their own int64_t on platforms that don't have it when trying to build 
libarchive. I'm assuming this was done as a special case for Windows, but 
really should have been designed to be more generic.

Also, I believe the end-goal is to build cmake on SCO 5 which imports 
libarchive, and doesn't use autoconf/automake/libtool build chain, and the 
CMakeLists.txt does not properly define the int64_t and friend datatypes for 
building. Even if it did, external callers wouldn't be able to build with it 
unless they also did the same int64_t logic which is probably inappropriate.

Finally, I think it is improper to have code duplication defining __LA_INT64_T 
in 2 public header files (archive.h and archive_entry.h), which this patch also 
appears to resolve.

Original comment by bradley....@gmail.com on 20 Jan 2011 at 4:28

[GoogleCodeExporter]

"...the CMakeLists.txt does not properly define the int64_t and friend 
datatypes for building."

Please help us fix it.  If you can verify for us that the autoconf toolchain 
works on SCO 5, then we can adapt the techniques used there.

"... external callers wouldn't be able to build with it unless they also did 
the same int64_t logic which is probably inappropriate."

External callers can use __LA_INT64_T.

Original comment by kientzle@gmail.com on 21 Jan 2011 at 6:24

• Changed title: build fails on SCO 5
• Added labels: OpSys-Other
• Removed labels: OpSys-All

[GoogleCodeExporter]

Shortly after ./configure && make:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/usr/local/include/libxml2 -Wall 
-Werror -g -O2 -MT libarchive/archive_acl.lo -MD -MP -MF 
libarchive/.deps/archive_acl.Tpo -c libarchive/archive_acl.c  -fPIC -DPIC -o 
libarchive/.libs/archive_acl.o
In file included from libarchive/archive_string.h:47,
                 from libarchive/archive_acl_private.h:35,
                 from libarchive/archive_acl.c:33:
libarchive/archive.h:49:44: inttypes.h: No such file or directory
libarchive/archive_acl.c: In function `archive_acl_parse_w':
libarchive/archive_acl.c:604: warning: implicit declaration of function 
`wmemcmp'
make[1]: *** [libarchive/archive_acl.lo] Error 1

Original comment by brianchi...@gmail.com on 21 Jan 2011 at 8:45

[GoogleCodeExporter]

I just committed r2934, which fixes the use of wmemcmp in archive_acl.c

I've also committed r2935, which changes archive.h and archive_entry.h to not 
include inttypes.h if _SCO_DS is defined.  It also defines __LA_INT64_T to be 
"long long" on that platform.

I think I've figured out a way to simplify some of the configuration logic for 
determining a 64-bit integer type.  It will take me a couple of days to get 
that in place.

(As an aside:  I intend to remove the __LA_UID_T, __LA_GID_T, __LA_MODE_T 
definitions from the public interface soon.  mode_t can be replaced with 'int' 
on every platform that I know of, and we need to ensure the use of 64-bit 
integers for UID and GID so as to not lose information when reading archives 
created on platforms that use large UIDs and GIDs.  I'm still trying to work 
out a proper transition strategy for that change so that it's not too 
disruptive for people.  After that, the only special type definitions in the 
public interfaces will be __LA_INT64_T, __LA_SSIZE_T, and __LA_DEV_T.)

Original comment by kientzle@gmail.com on 22 Jan 2011 at 7:50

[GoogleCodeExporter]

Commit r2939 to trunk adds a bunch of logic to the CMake build that ensures 
int64_t, int32_t, etc, are all correctly defined.

This should address most of the issues seen on SCO 5.  I'd appreciate if you 
could try a cmake build of libarchive/trunk and let me know what problems 
you're still having.

Original comment by kientzle@gmail.com on 23 Jan 2011 at 6:16

[GoogleCodeExporter]

Thank you, that helped a lot. Here are some remaining issues.

libarchive/archive_read_disk_posix.c:2059
readdir_r has a different number of parameters on SCO. Plain readdir is OK.

libarchive/archive_read_support_format_mtree.c:631
SCO doesn't define S_IFSOCK.

libarchive/archive_write_disk.c:260: warning: `edit_deep_directories' declared 
`static' but never defined
I fixed this by conditioning the forward declaration the same way its uses are 
conditioned:
#if defined(HAVE_FCHDIR) && defined(PATH_MAX)

libarchive/archive_write_set_format_iso9660.c:5242
SCO doesn't define NAME_MAX.

libarchive/archive_write_set_format_pax.c:832: warning: comparison is always 
false due to limited range of data type                                         

lines 832, 853, 1089, 1093
Probably due to dev_t, uid_t, gid_t having sizeof(2). sys/types defines dev_t 
as short, uid_t and gid_t as unsigned short.

command line: fatal error: illegal value for -R: /usr/local/lib                 

It seems upset about '-Wl,-R,/usr/local/lib'.

Other than that, I think it would build. Again, thanks very much.

Original comment by brianchi...@gmail.com on 23 Jan 2011 at 10:24

[GoogleCodeExporter]

Most of these have just been addressed in the last few hours:

> libarchive/archive_read_disk_posix.c:2059
> readdir_r has a different number of parameters on SCO. Plain readdir is OK.

I just committed a change to the CMakeLists.txt to explicitly test for the 
POSIX-compatible 3-argument version.

> libarchive/archive_read_support_format_mtree.c:631
> SCO doesn't define S_IFSOCK.

I committed a change to this file that should address this problem.

> libarchive/archive_write_disk.c:260: warning: `edit_deep_directories' 
declared `static' but never defined
> I fixed this by conditioning the forward declaration the same way its uses 
are conditioned:
> #if defined(HAVE_FCHDIR) && defined(PATH_MAX)

I've committed this change.

> libarchive/archive_write_set_format_iso9660.c:5242
> SCO doesn't define NAME_MAX.

Michihiro just committed a fix for this.

> libarchive/archive_write_set_format_pax.c:832: warning: comparison is always 
false ...

I've just committed a change that should fix this.

> command line: fatal error: illegal value for -R: /usr/local/lib               

> It seems upset about '-Wl,-R,/usr/local/lib'.

I'm not sure about this one.  Is this with the autoconf-generated build system 
or with cmake?
Thanks again for helping us work through this.

Original comment by kientzle@gmail.com on 24 Jan 2011 at 5:49

[GoogleCodeExporter]

Those patches helped a lot. Thanks.

>> readdir_r has a different number of parameters on SCO. Plain readdir is OK.

> I just committed a change to the CMakeLists.txt to explicitly test for the 
POSIX-compatible 3-argument version.

Thank you. But it still seems to be a problem with the autoconf-generated build 
system.

libarchive/archive_read_support_format_lha.c:1811: warning: `c' might be used 
uninitialized in this function
This is only a problem because of -Werror, but I thought I should mention it.

The -Wl,-R,/usr/local/lib problem happens in the autoconf build system.

Thanks very much for working on this.

Original comment by brianchi...@gmail.com on 24 Jan 2011 at 4:47

[GoogleCodeExporter]

> command line: fatal error: illegal value for -R: /usr/local/lib               

> It seems upset about '-Wl,-R,/usr/local/lib'.

I tinkered a little, but I'm not sure I understand this one.  With GCC, the 
-Wl,-R,/usr/local/lib means that the following option should get passed to the 
linker ld:
   -R /usr/local/lib

It sounds like 'ld' on your system doesn't accept that option.  Unfortunately, 
that's not handled by anything in libarchive; we rely on GNU autoconf and GNU 
libtool to understand how to actually link programs on your system.  What 
version of autoconf and libtool are you using?

Original comment by kientzle@gmail.com on 25 Jan 2011 at 5:39

[GoogleCodeExporter]

autoconf 2.63, libtool 2.2.6.

Original comment by brianchi...@gmail.com on 25 Jan 2011 at 4:05

[GoogleCodeExporter]

After ./configure,
$ sed -i -e 's|hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|' 
libtool
seems to fix the -Wl,-R,/usr/local/lib problem. I don't know what's putting 
that in libtool, though.

If I don't specify --without-bz2lib on ./configure, I get
relocations referenced
        from file(s)
        /usr/local/lib/libbz2.a(bzlib.o)
        /usr/local/lib/libbz2.a(compress.o)
        /usr/local/lib/libbz2.a(decompress.o)
        /usr/local/lib/libbz2.a(blocksort.o)
        /usr/local/lib/libbz2.a(huffman.o)
 fatal error: relocations remain against allocatable but non-writable section: .text

I think this may be due to the fact that this system, for whatever reason, 
doesn't have libbz2.so, only libbz2.a. Just mentioning it in case you know 
differently.

The last problem is
tar/tree.c:126: error: parse error before "HANDLE"
due to the presence of a windows.h unrelated to the operating system by 
Microsoft.

After that, it's built!

Original comment by brianchi...@gmail.com on 25 Jan 2011 at 9:14

[GoogleCodeExporter]

r2949 fixes the problem in tar/tree.c.   Thanks for pointing that out, that was 
a silly mistake.

The libtool issue confuses me.  It could be a libtool bug, a bug in 
libarchive's configure.ac or Makefile.am files, or a problem with how some 
libraries are installed on your system.  I don't really have information to 
even guess which one.  If you do figure it out, please let us know.

If you feel inclined to do so, I'd be very interested in whether the cmake 
build works on your system; I've recently added a bunch of additional 
configuration logic to the cmake build inspired by some of the issues you've 
raised here.

Original comment by kientzle@gmail.com on 26 Jan 2011 at 4:38

[GoogleCodeExporter]

I did find a clue about the libtool issue.  The online man pages for SCO 5.0.7 
document that the -R option to ld does not behave at all the way libtool is 
using it on your system:

http://osr507doc.sco.com/en/man/html.CP/ld.CP.html

By any chance are you using GCC or some other alternate compiler with the 
standard system linker?  That may be part of the confusion here.

Original comment by kientzle@gmail.com on 26 Jan 2011 at 4:56

• Changed state: Waiting

[GoogleCodeExporter]

We made a breakthrough on the libtool -R thing. Our 
/usr/local/lib/lib{expat,xml2}.la have libdir='/usr/local/lib' lines. Moving 
those .la files where libtool couldn't find them seems to have fixed the 
problem. I think we can consider that issue solved.

We *are* using GCC and the standard system linker. SCO's native compiler 
doesn't have 64-bit integer support, and GNU binutils didn't seem to provide ld 
for SCO.

Testing the cmake build of libarchive on SCO is problematic because right now 
it's hard to build cmake on SCO without numerous patches. I'm hoping that the 
recent improvements will make it easier. I'll try replacing the older version 
of libarchive that cmake includes with libarchive trunk. Thanks.

Original comment by brianchi...@gmail.com on 26 Jan 2011 at 10:20

[GoogleCodeExporter]

libarchive/archive_read_disk_posix.c:2060 from trunk still tries to use 
readdir_r. GCC complains "too many arguments". Thanks.

Original comment by brianchi...@gmail.com on 26 Jan 2011 at 10:25

[GoogleCodeExporter]

r2952 changes configure.ac to only look for the three-argument POSIX version of 
readdir_r.  Systems that don't have that version will fall back to the 
non-thread-safe readdir() function.

Original comment by kientzle@gmail.com on 27 Jan 2011 at 5:56

[GoogleCodeExporter]

r2953 implements the same for the CMake build.

Original comment by kientzle@gmail.com on 27 Jan 2011 at 6:30

[GoogleCodeExporter]

I pulled cmake and libarchive trunks. I moved cmake's cmlibarchive/ and created 
a new one containing code from libarchive trunk.

After cmake bootstrap, 'make' in cmlibarchive/ fails due to my system's lack of 
dynamic libbz2. I don't see how to disable that correctly, so I just had to 
comment the commands inside the IF(BZIP2_FOUND) block in CMakeLists.txt.

Then:
test/test_sparse_basic.c:272: error: `PATH_MAX' undeclared (first use in this 
function)

Then, in
test_read_data_large.c
test_read_truncated.c
test_write_compress_program.c
test_write_format_ar.c
test_write_format_gnutar.c
test_write_format_iso9660_boot.c
test_write_format_iso9660.c
test_write_format_iso9660_zisofs.c
test_write_format_pax.c
test_write_format_tar.c
there are some 'buff' and 'buff2' variables that differ in size, so I made them 
static.

Then, trying to build libarchive_test fails because -lsocket is needed.

Then, trying to build libarchive_test fails due to some problem with zlib:
Undefined             first referenced
 symbol                in file
inflateEnd            ../libarchive.a(archive_read_support_compression_gzip.c.o)
inflateInit_          ../libarchive.a(archive_read_support_format_iso9660.c.o)
deflateReset          ../libarchive.a(archive_write_set_format_iso9660.c.o)
deflateInit2_         ../libarchive.a(archive_write_add_filter_gzip.c.o)
inflateInit2_         ../libarchive.a(archive_read_support_compression_gzip.c.o)
inflateReset          ../libarchive.a(archive_read_support_format_cab.c.o)
deflate               ../libarchive.a(archive_write_add_filter_gzip.c.o)
crc32                 ../libarchive.a(archive_read_support_compression_gzip.c.o)
deflateEnd            ../libarchive.a(archive_write_add_filter_gzip.c.o)
inflate               ../libarchive.a(archive_read_support_compression_gzip.c.o)
deflateInit_          ../libarchive.a(archive_write_set_format_iso9660.c.o)
inflateSetDictionary  ../libarchive.a(archive_read_support_format_cab.c.o)

We think it may be due to using cmake's bundled zlib, but the system zlib.h. To 
get past it, I set CMAKE_USE_SYSTEM_ZLIB TRUE.

Then, trying to build bsdtar fails because -lsocket is needed.

Then, trying to build cpio fails because -lsocket is needed.

Then:
[ 98%] Building C object 
Utilities/cmlibarchive/cpio/test/CMakeFiles/bsdcpio_test.dir/test_owner_parse.c.
o
In file included from 
/brian/cmake/Utilities/cmlibarchive/cpio/cpio_platform.h:42,
                 from /brian/cmake/Utilities/cmlibarchive/cpio/cpio.h:31,
                 from /brian/cmake/Utilities/cmlibarchive/cpio/test/test_owner_parse.c:28:
/brian/cmake/Utilities/cmlibarchive/config.h:159: error: redefinition of 
`intmax_t'
/brian/cmake/Utilities/cmlibarchive/config.h:159: error: `intmax_t' previously 
declared here
/brian/cmake/Utilities/cmlibarchive/config.h:163: error: redefinition of 
`uintmax_t'
/brian/cmake/Utilities/cmlibarchive/config.h:163: error: `uintmax_t' previously 
declared here

Thanks again for all your effort.

Original comment by brianchi...@gmail.com on 31 Jan 2011 at 6:22