search for: posixy

Samuel Crow wrote: > Are you still using Cygwin? > Why not try using MinGW instead. It was available. I live in Cygwin; MSYS is a poor alternative. Also generally speaking, open source projects targeting a POSIXy environment have a higher probability of working first time with Cygwin, so it serves well for investigation (e.g. no distribution in the GPL sense). > I think Cygwin cannot create .DLL files It can. > or if it can, > the build scripts are not set up to do it from Cygwin. I was able t...

On Jan 26 22:00, Nico Kadel-Garcia wrote: > On Sat, Jan 26, 2019 at 6:30 PM Corinna Vinschen <vinschen at redhat.com> wrote: > > > > On Jan 26 18:12, Nico Kadel-Garcia wrote: > > > On Sat, Jan 26, 2019 at 5:07 PM Corinna Vinschen <vinschen at redhat.com> wrote: > > > > > > > > Microsoft hijacked the sshd service name without asking. >

Hello Barry, Are you still using Cygwin? Why not try using MinGW instead. I think Cygwin cannot create .DLL files or if it can, the build scripts are not set up to do it from Cygwin. IIRC, Cygwin support is being dropped from later versions of LLVM so you'll have to either use Visual C++ to compile it or MinGW. See http://www.mingw.org for downloads. --Sam ----- Original Message ----

Full_Name: Jens Oehlschl?gel Version: 2.10.0 OS: Windows XP Professional Submission from: (NULL) (85.181.158.112) file.rename() will successfully rename file a to b - even if b exists already. Though the documentation does not state what file.rename() will do in this case, I guess the expected behaviour is to fail and return FALSE. Kind regards Jens Oehlschl?gel > cat("a\n",

I'm looking to get started with LLVM as the back end for a compiler that ultimately should self-host. >From an ease of use perspective, the optimum on Windows would be a DLL along with C header files that I can translate into the front end's language. I read in the FAQ: http://llvm.org/docs/FAQ.html#langs that "the C bindings in include/llvm-c should help a lot". However,

Hello, I was wondering how folks were feeling about replacing the default Windows CRT allocator in Clang, LLD and other LLVM tools possibly. The CRT heap allocator on Windows doesn't scale well on large core count machines. Any multi-threaded workload in LLVM that allocates often is impacted by this. As a result, link times with ThinLTO are extremely slow on Windows. We're observing

...o compile twice and link twice (compile same program with cl and clang-cl, then link both with lld). The fundamental difference here is that we have two different things that can emit debug info - the compiler and linker - and we need the flexibility to test both independently of each other. On a posixy platform, you only care the compiler and don't care what the linker is. On the other hand, it has its own set of unique aspects. You might decide to compile and link many times, so that you can test -gsplit-dwarf, -gdebug-info-kind=limited, -gdebug-info-kind=full, -gdb-index, etc. against a s...

I was thinking of something along the lines of: // SCRIPT-POSIX: posix/aggregate-indirect-arg.s // SCRIPT-WIN: win/aggregate-indirect-arg.s class SVal { public: ~SVal() {} const void* Data; unsigned Kind; }; void bar(SVal &v) {} class A { public: void foo(SVal v) { bar(v); } }; int main() { SVal v; v.Data = 0; v.Kind = 2142; A a; a.foo(v); return 0; } Then, you could