Finally had some spare time to look into getting OpenPKG to work on Tru64 again. I'm going to concentrate on getting V2.0 in shape on Tru64, instead of tracking current (as that is a moving target). At the moment, V2.0 doesn't bootstrap on Tru64.



The following stuff caused problems:


* CURL


Problem:

curl V7.11 doesn't compile when strtoll() isn't available. This was fixed in curl V7.11.1
see http://curl.haxx.se/changes.html : builds with large file support even on systems without strtoll()


Fix:

Have openpkg.spec use version V7.11.1 of curl.




* RPM getopt


Problem:

file/file.c and tools/rpmfile.c assume that the presence of getopt.h means that getopt_long/struct option exists. This is not true on Tru64.

E.g. in file/file.c :

#ifndef HAVE_GETOPT_H
       while ((c = getopt(argc, argv, OPTSTRING)) != -1)
#else
       while ((c = getopt_long(argc, argv, OPTSTRING, long_options,
           &longindex)) != -1)
#endif


But /usr/include/getopt.h on Tru64 only defines:


#ifndef _GETOPT_H_
#define _GETOPT_H_

#include <standards.h>

#if defined(__cplusplus)
extern "C"
{
#endif
extern int getopt __((int, char * const [], const char *));
#if defined(__cplusplus)
}
#endif

extern char *optarg;
extern int optind;
extern int optopt;
extern int opterr;

#endif /* _GETOPT_H_ */



Fix:

Put ac_cv_header_getopt_h=no in the config.cache file of the rpm configure. I'm not sure how this is best resolved so that it works for all platforms.

# cheat GNU Autoconf
( echo 'ac_cv_path_MSGFMT=:'
echo 'ac_cv_path_GMSGFMT=:'
echo 'ac_cv_path_XGETTEXT=:'
echo 'ac_cv_path_MSGMERGE=:'
echo "ac_cv_path_MKDIR='%{l_prefix}/lib/openpkg/shtool mkdir -f -p -m 755'"
echo "ac_cv_path___MKDIR='%{l_prefix}/lib/openpkg/shtool mkdir -f -p -m 755'"
echo "ac_cv_path___PYTHON=true"
echo "ac_cv_path___DOXYGEN=true"
echo "acl_cv_rpath=no"
echo "ac_cv_header_getopt_h=no"
) >config.cache


This is how I tested it.


Another possibility would be to fix the configure script to check for the presence of getopt_long.






* RPM file

Problem:

There are problems with the intXX_t macros in the file/ subdirectory.

Fix:

The ISO C99 header inttypes.h, which exists on Tru64, has the correct macros. The autoconf script already tests for the presence of this header, so we can use it if HAVE_INTTYPES_H is defined. Following patch to rpm-4.2.1/file/system.h resolves this:

#include <sys/types.h>
+#ifdef HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif




* RPM rpmrpc.c


Problem:

dirent fiddling patch of rpm.patch.porting needs to be extended to support Tru64.

Fix:

Add __osf__ check in the correct place:

+#if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__) && !defined(sun) && !defined(OPENPKG_UNIXWARE) &&
!defined(OPENPKG_DARWIN) && !defined(__osf__)
+#define SETFTPMAGIC(_dir) ((_dir)->fd) = ftpmagicdir
+#define ISFTPMAGIC(_dir) ((_dir)->fd == ftpmagicdir)
+#else
+#define SETFTPMAGIC(_dir) ((_dir)->dd_fd) = ftpmagicdir
+#define ISFTPMAGIC(_dir) ((_dir)->dd_fd == ftpmagicdir)
+#endif


and..

+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(OPENPKG_DARWIN)
+ dp->d_ino = i + 1;
+ dp->d_reclen = 0;
+ dp->d_type = av[i].type;
+ strncpy(dp->d_name, av[i].name, sizeof(dp->d_name) - 1);
+ dp->d_name[sizeof(dp->d_name)-1] = '\0';
+ dp->d_namlen = strlen(dp->d_name);
+#elif defined(hpux) || defined(sun) || defined(OPENPKG_UNIXWARE) || defined(__osf__)
+ /* XXX glob(3) uses REAL_DIR_ENTRY(dp) test on d_ino */
+ dp->d_ino = i + 1; /* W2DO? */
+ dp->d_reclen = 0; /* W2DO? */
+ strncpy(dp->d_name, av[i].name, sizeof(dp->d_name));
+#else






* RPM fts.c

Problem:

Build errors about errno, dirent etc..

Fix:

Update fix in rpm.patch.porting with __osf__ specific defines:

+#if defined(__osf__)
+#   define __errno_location()   (&errno)
+#   define dirfd(dirp)          -1
+#   define stat64               stat
+#   define _STAT_VER            0
+#   define __fxstat64(_stat_ver, _fd, _sbp)     fstat((_fd), (_sbp))
+#   define _D_EXACT_NAMLEN(d) ((d)->d_namlen)
+#endif





______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   [EMAIL PROTECTED]

Reply via email to