search for: os_types

In order to compile the latest Vorbis library on the Macintosh, the change appended to this message needs to be made to os_types.h.in. Then, anyone who wants to actually build it must first copy os_types.h.in to os_types.h by hand, since MacOS does not include a command line and thus cannot run configure. It really bugs me that the whole "platforms which don't support configure scripts require multiple undocume...

I decided, since nobody else seems to be doing it, to do a new build of the Mac library. Unfortunately, things now rely on os_types.h. No problem, I'll just create an os_types.h in mac/compat. Except os.h #includes "../include/vorbis/os_types.h" -- in other words, it explicitly wants the os_types.h that was generated from os_types.h.in by configure. The simple solution is to just #include "os_types.h&qu...

R Extensions (Section 1.1.1, and using the 2.9.2 version) says The optional `OS_type' field specifies the OS(es) for which the package is intended. If present, it should be one of `unix' or `windows', and indicates that the package should only be installed on a platform with `.Platform$OS.type' having that value. and I am wondering if 'OS_type: unix' includes

The current CVS tree (08/27/00) has a typo in os_types.h, simply missing a "ty", I have pasted the diff below: Index: os_types.h =================================================================== RCS file: /usr/local/cvsroot/vorbis/include/vorbis/os_types.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -r1.1.1.1 -r1.2 17c17 &lt...

Hi folks, Debian 504 64-bit What is the correct syntax to check the available of a package on R repo? > available.packages("emacs", "OS_type=linux") Warning: unable to access index for repository emacs Package Version Priority Depends Imports LinkingTo Suggests Enhances OS_type License File Repository > available.packages("emacs") Warning: unable

Hey guys, Maybe its cause I'm using older tools, but I've noticed a minor problem building the ogg libraries on a mac. I'm using Codewarrior 8. In os_types.h on line 60, it says "#include <sys/types.h>" where it should be "#include <types.h>" I'm guessing this isn't an issue for all compilers, just codewarrior. Possibly only codewarrior 8 and not codewarrior 9 as well. I just manually changed my include file...

...IBS) 42c43 < vorbize: vorbize.o --- > vorbize: vorbize.o $(VORBISLIBS) 45a47,48 > ../cmdline/getopt.a: > cd ../cmdline && make getopt.a 58c61 < $(INSTALL) -b -m 711 mp3tovorbis @prefix@/bin/ --- > $(INSTALL) -b -m 755 mp3tovorbis @prefix@/bin/ Index: include/vorbis/os_types.h =================================================================== RCS file: /usr/local/cvsroot/vorbis/include/vorbis/os_types.h,v retrieving revision 1.5 diff -r1.5 os_types.h 26c26 < #ifdef __BEOS__ --- > #if defined (__BEOS__) || (defined(__unix__) && defined(__digital__)) ---...

(i hope this is correct m.list) Hi, there is a small compiling problem for mingw when compiling on libogg.. in include/ogg/os_types.h : ogg_int64_t, ogg_int32_t, etc are defined correctly on cygwin and MSVC/Borland but not on mingw... i have attached a patch that will fix this problem (i hope it attaches correctly) thx, Nehal --- os_types.h.old Fri Jul 19 02:25:52 2002 +++ os_types.h Tue Dec 10 14:15:44 2002 @@ -32,6 +32,...

We've now implemented an OS_type field in a package's DESCRIPTION file, which if set has to match .Platform$OS.type (possible values "unix" and "windows"). CRAN has set up some overrides and added this field to packages known to be Unix-only or Windows-only, but authors should do so for themselves in future. Unsuitable packages will not be offered by

I checked the capabilities. I do not know why the guest is only for vbox. <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <domain type='vbox'> </domain> </arch> </guest> I want it run qemu-kvm. and when i run virsh define /etc/libvirt/qemu/demo.xml. It shows error:

...T=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -I. -I. -I../include -I../include -O20 -fsigned-char -g -O2 -c framing.c -MT framing.lo -MD -MP -MF .deps/framing.TPlo -DDLL_EXPORT -DPIC -o .libs/framing.lo In file included from ../include/ogg/ogg.h:24, from framing.c:25: ../include/ogg/os_types.h:38:26: _G_config.h: No such file or directory In file included from ../include/ogg/ogg.h:24, from framing.c:25: ../include/ogg/os_types.h:39: parse error before "ogg_int64_t" ../include/ogg/os_types.h:39: warning: data definition has no type or storage class ../include...

This is essentially a line-for-line translation of the C inspection code. --- daemon/Makefile.am | 8 + daemon/inspect.ml | 396 ++++++++++++++++++++ daemon/inspect.mli | 41 ++ daemon/inspect_fs.ml | 363 ++++++++++++++++++ daemon/inspect_fs.mli | 23 ++ daemon/inspect_fs_unix.ml | 788

From: Nikolay Ivanets <stenavin@gmail.com> Inspection code checks /etc/mdadm.conf to map MD device paths listed in mdadm.conf to MD device paths in the guestfs appliance. However on some operating systems (e.g. Ubuntu) mdadm.conf has alternative location: /etc/mdadm/mdadm.conf. This patch consider an alternative location of mdadm.conf as well. --- daemon/inspect_fs_unix_fstab.ml | 13

Even though the list of checks is very short, at least this migrates from imperative checks to a "declarative" one. There should be no behaviour change, other than using os-release if it contains all the needed information. --- daemon/inspect_fs_unix.ml | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/daemon/inspect_fs_unix.ml

This is essentially a line-for-line translation of the C inspection code. --- daemon/Makefile.am | 8 + daemon/inspect.ml | 396 +++++++++++++++++++++ daemon/inspect.mli | 41 +++ daemon/inspect_fs.ml | 363 +++++++++++++++++++ daemon/inspect_fs.mli | 23 ++ daemon/inspect_fs_unix.ml | 745

Why does the source use `int64_t'. Is this suppose to be built with GCC? I have Mumit Kahns gcc, version 2.8.1. Do I need a 2.9.5 version to get the `int64_t' type? I have substituted a typedef of `long long' in os_types.h. This seems to make sense? The rint() macro also seems to be having some problems. I guess there are two meanings to __GNUC__ and _WIN32. One is the OS and the other is the compiler type. I tried the .dsw file in the distribution with VC6.00.2???, but nothing happened when I attempted to loa...

On Monday, 31 July 2017 17:40:57 CEST Richard W.M. Jones wrote: > +(* Parse a os-release file. > + * > + * Only few fields are parsed, falling back to the usual detection if we > + * cannot read all of them. > + * > + * For the format of os-release, see also: > + * http://www.freedesktop.org/software/systemd/man/os-release.html > + *) > +let rec parse_os_release

In the file os_types.h (ogg/include/ogg) cygwin (newest version) complains about some error on line 43. Apparently "typedef unsigned _G_int32_t ogg_uint32_t;" is an illegal line .. Anyone have any idea why ? .. Anyway, if "unsigned _G_int32_t" is replaced by "_G_uint32_t", cygwin compiles...

No change, just reposting without the "for discussion" tag. I think we should allow this as it seems like a nice coding style for a limited subset of imperative-style code. Rich.

When rewriting the heavily imperative original inspection code, I longed for a ‘return’ statement so I could keep the new code as close as possible to the original. OCaml of course does not have such a statement, but it's relatively simply to implement it in the language. The first patch does so, and the second patch rewrites a sample of the inspection code to use it. Rich.