|
Notes |
|
|
(0020168)
|
|
Bill Hoffman
|
|
2010-04-13 15:12
|
|
|
Is there no sleep function that can be called on Tru64? |
|
|
|
(0020170)
|
|
Daniel Richard G.
|
|
2010-04-13 16:23
|
|
sleep(3) is available, and in fact usleep() is available, but the only way I could get to it (without breaking other things in that source file) was to add
#define _OSF_SOURCE
#define _POSIX_C_SOURCE 20100101 /* "1" didn't work */
#define _XOPEN_SOURCE_EXTENDED
at the top. Hacking it with select() might be easier than navigating a maze of feature test macros.... |
|
|
|
(0020174)
|
|
Bill Hoffman
|
|
2010-04-13 17:43
|
|
|
Sounds like a flag might do the trick to get the functions to work. I don't think a select hack is a good idea if the system has this stuff. |
|
|
|
(0020177)
|
|
Daniel Richard G.
|
|
2010-04-13 18:02
|
|
How do you determine which ones to use, however? I had to hunt through headers and do trial and error just to get that one file to compile. With one combination, you lose lstat(); with another, you lose TIOCGWINSZ; another, a bajillion things break; and so on. I don't see a straightforward way of determining the necessary mix, other than a configure-time test that basically iterates through all the possible permutations.
My suggestion would be to just do a HAVE_USLEEP check, let the user worry about that failing or not, and implement the select() hack as the fallback. That takes care of this, and any two-bit system that doesn't have usleep() at all. |
|
|
|
(0020358)
|
|
Daniel Richard G.
|
|
2010-04-22 14:04
|
|
|
The attached patch kinda/sorta fixes this bug, but of course is targeted only at Tru64. I think the best fixes is HAVE_USLEEP and the select() fallback. Some systems out there really aren't going to have usleep(), you know.... |
|
|
|
(0020541)
|
|
Bill Hoffman
|
|
2010-05-04 14:44
|
|
|
I have applied this patch. Please try. Also, are you ready to start running nightly dashboards? |
|
|
|
(0020565)
|
|
Daniel Richard G.
|
|
2010-05-04 17:37
|
|
I'm already running the dashboard on Tru64 regularly (see tru64.teragram). It's the Solaris 8 dashboard (solaris8.teragram) that's giving me trouble---it bombs out in the configure stage, but this only happens when I run the dashboard, not when I build manually.
Anyway, SystemTools.cxx now compiles correctly. Still getting a lot of errors due to a missing inttypes.h/stdint.h header, however. Have you talked with libarchive's upstream about the fixes in my big patch? |
|
|
|
(0020581)
|
|
Bill Hoffman
|
|
2010-05-05 09:39
|
|
I am not sure we can get all the libarchive stuff upstream. I would like to focus on CMake's version right now.
What are the errors about inttypes.h stdint.h? |
|
|
|
(0020583)
|
|
Bill Hoffman
|
|
2010-05-05 09:53
|
|
/*
* Note: archive.h is for use outside of libarchive; the configuration
* headers (config.h, archive_platform.h, etc.) are purely internal.
I see the inttype stuff on the dashboard...
Is there some inttype file that we can include for this system?
From archive.h:
* Do NOT use HAVE_XXX configuration macros to control the behavior of
* this header! If you must conditionalize, use predefined compiler and/or
* platform macros.
*/
#if defined(__BORLANDC__) && __BORLANDC__ >= 0x560
# define __LA_STDINT_H <stdint.h>
#elif !defined(__WATCOMC__) && !defined(_MSC_VER) && !defined(__INTERIX) && !defined(__BORLANDC__)
# define __LA_STDINT_H <inttypes.h>
#endif |
|
|
|
(0020585)
|
|
Daniel Richard G.
|
|
2010-05-05 10:54
|
|
That's the thing; neither header exists on this system. There is nothing under /usr/include that defines the u?int(8|16|32|64)_t types. You have to provide the definitions. (LA only needs like one or two of these, however---see my patch.)
You could tweak that cpp code to not touch __LA_STDINT_H if it's already #defined, and then pass in e.g. -D__LA_STDINT_H=libarchive_stdint.h on the command line. But what the LA folks really need to do is create archive.h from archive.h.in with the appropriate header file reference substituted in, and not use cpp conditionals at all for that. |
|
|
|
(0020586)
|
|
Bill Hoffman
|
|
2010-05-05 11:18
|
|
How about this:
#if Tru64
# define __LA_STDINT_H "la_tru64_inttypes.h"
...
Then create a la_tru64_inttypes.h that gets put right next to archive.h. Can you try something like that? I would like to get this working in CMake's version first, then I will see about pushing upstream.
Thanks. |
|
|
|
(0020636)
|
|
Daniel Richard G.
|
|
2010-05-06 20:08
|
|
Okay, I sort of have things working with CMake's copy of libarchive. One wrinkle I encountered is that the id_t type is defined only if you #define _OSF_SOURCE or _XOPEN_SOURCE_EXTENDED. I hacked around this in my patch, but this is really crying out for a better solution (HAVE_ID_T). In general, libarchive needs to get its ducks in a row with regards to types that the system may not be providing.
How does this patch (stdint-fix.patch) look to you? |
|
|
|
(0022072)
|
|
Bill Hoffman
|
|
2010-09-02 09:26
|
|
|
Can you try the better stdint patch that I uploaded? It should work, and does the same thing windows does pretty much. |
|
|
|
(0022078)
|
|
Daniel Richard G.
|
|
2010-09-02 18:24
|
|
It's an improvement, but some issues remain:
* The new int64_t/uint32_t/uint64_t definitions help in building libarchive, but then three source files in CPack and CMake proper that make use of libarchive don't get those definitions, and break.
* archive.h still tries to pull in inttypes.h, which doesn't exist on this system.
* For some reason, libarchive finds the id_t type during configuration, but then can't find it when building. This typedef can be obtained from <sys/types.h> when _OSF_SOURCE is #defined, so I just added that to libarchive's config.h.
I've sent you et al. more detailed information via e-mail. |
|
|
|
(0041682)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
cmake-10542-semi-fix.patch (711) 2010-04-22 14:05