search for: _portable_

Just went and cvs co'd portable openssh as described on the website. However, there's no configure there. nor there's a build.conf script of some sort to rebuild it. When I manually did autoconf configure.ac > configuire, I got something, but it couldn't find config.h.in when running. An attempt to run automake said that aclocal.m4 is obsolete and I need to rerun aclocal, but

...ion { int, char* }; > > Number 3 doesn't exist in LLVM and is what I'm proposing. A union type is not needed if you encode some simple properties of the target (like the pointer size) into the bytecode file, which we do with the C/C++ front-end. The only question then is how to make _portable_ bytecode files with "unions". I'm not really sure what the answer is here. I would really like to avoid adding a new union type, as it is not needed at the LLVM level, and it seems like high-level languages can map source-level unions onto existing LLVM operations. In Stacker, for...

As a side effect of bug 178 (Stacker not handling 64-bit pointers on Solaris), I got thinking about a union type for LLVM. Is there any good reason that LLVM shouldn't support unions? This is essentially a structure that has its members all at the same address rather than at sequential addresses. I know there are various issues with unions (alignment, etc.) but wouldn't it make sense to

I have run across an interesting issue when running rsync from Solaris to an rsync daemon on Linux. It works properly when I specify the password on the command line: RSYNC_PASSWORD=the_Password rsync -r /tmp/test test_user@test_server::test_user/topdir/subdir However, if I do not specify the password on the command line and am prompted interactively, it always fails. After some

...ng easier, but I understand the minimalist approach that LLVM needs to maintain. > A union type is not needed if you encode some simple properties of the > target (like the pointer size) into the bytecode file, which we do with > the C/C++ front-end. The only question then is how to make _portable_ > bytecode files with "unions". I'm not really sure what the answer is > here. Me either :( > I would really like to avoid adding a new union type, as it is not needed > at the LLVM level, and it seems like high-level languages can map > source-level unions onto exis...