Re: haproxy, Windows, pull requests
ok, I switched the compiler to pure clang instead of clang-cl (frontend to MSVC), and it went a lot better. You can look at https://github.com/amoldeshpande/haproxy There's just one commit with the shared code. Since I don't have it really running I can't say if the LLP64 things will cause any runtime problems yet. On Tue, Oct 29, 2019 at 10:42 AM Willy Tarreau wrote: > On Tue, Oct 29, 2019 at 10:29:43AM -0700, Amol Deshpande wrote: > > The short answer as to why is that in the games industry Windows servers > > are not unknown. Plus during development it's helpful to have the ability > > to run all servers locally on a developer's computer, which is usually > > Windows for PC games. > > Ah I can indeed see that there's a valid case in this area. > > > The long problems were not too bad, since the compiler is pretty hardcore > > about truncations. Honestly there were a lot more size_t to int > conversions > > than any long to pointers. > > OK, so let's have a look. > > > I'll upload what I have to my github sometime this week and send you a > > link. > > Thanks! > Willy >
Re: haproxy, Windows, pull requests
On Tue, Oct 29, 2019 at 10:29:43AM -0700, Amol Deshpande wrote: > The short answer as to why is that in the games industry Windows servers > are not unknown. Plus during development it's helpful to have the ability > to run all servers locally on a developer's computer, which is usually > Windows for PC games. Ah I can indeed see that there's a valid case in this area. > The long problems were not too bad, since the compiler is pretty hardcore > about truncations. Honestly there were a lot more size_t to int conversions > than any long to pointers. OK, so let's have a look. > I'll upload what I have to my github sometime this week and send you a > link. Thanks! Willy
Re: haproxy, Windows, pull requests
hi Willy, Yes, I do have strange hobbies :-) The short answer as to why is that in the games industry Windows servers are not unknown. Plus during development it's helpful to have the ability to run all servers locally on a developer's computer, which is usually Windows for PC games. Also, something of an academic curiosity for me personally. Like you said, strange hobbies :) The clang-cl warnings seem pretty obviously correct to me, and not just platform differences, but I'll play around with the frontend compiler and see if that changes anything. The long problems were not too bad, since the compiler is pretty hardcore about truncations. Honestly there were a lot more size_t to int conversions than any long to pointers. I'll upload what I have to my github sometime this week and send you a link. Thanks! -amol On Tue, Oct 29, 2019 at 9:56 AM Willy Tarreau wrote: > Hi Amol, > > On Sat, Oct 19, 2019 at 09:41:34AM -0700, Amol Deshpande wrote: > > hi, > > > > I've taken up a hobby task to make a native version of haproxy for > Windows, > > using some of the platform-specific features for network I/O. > > You're having strange hobbies in my opinion :-) > > > I've been using clang-cl to compile and it mostly works well. There are a > > lot of warnings generated in the code that fall into two categories: > > > > 1. General warnings that are probably the difference between clang being > > stricter than gcc. > > Do you have many of them? Some users (at least the ones on FreeBSD ans OSX > I guess) commonly use clang if my understanding is correct, and a quick > check at our CI on builds using clang doesn't indicate any warning, so > they might be partially related to the platform. > > > 2. Size difference between unsigned long on LLP64 (Windows) vs Unix > (mostly > > LP64, i guess). > > Oh yes this is by far the real issue with this platform: there is no > standard type which is the size of a native register on all archs. > You have to switch to size_t and consorts to work around this mess :-/ > > > The Windows stuff is a long way from a pull request yet, but if there is > > interest I can send a pull request on github for just the common code I > > have touched. It would be nice to have it upstreamed so I can concentrate > > on just the gnarly bits. > > > > Please let me know (please CC me as I'm not yet subscribed to this list) > > So I'm not sure there is any particular interest given that it's not > frequent to see that platform used on infrastructure components, and > even a number of developers who have the choice tend to move away from > it. However if the changes are minimal and non-intrusive, I'm not against > getting them merged, if at least this eases your task next time you have > to work on it. But I really have strong doubts regarding the type "long" > which is broken there :-/ > > Also do not bother sending a PR, they're automatically closed. We prefer > reviewable patches here on the ML. If there is a place where your code > is viewable (even if dirty, don't worry, we all know how it is during > porting) please just send a link, I'm curious to see how you managed > to work around all those longs we're using. > > Just a question, do you have a compelling use case or did you do it > only for fun ? > > Thank, > Willy >
Re: haproxy, Windows, pull requests
My 2 cents: "let's wait for Windows to adopt the Linux kernel"..
Re: haproxy, Windows, pull requests
Hi Amol, On Sat, Oct 19, 2019 at 09:41:34AM -0700, Amol Deshpande wrote: > hi, > > I've taken up a hobby task to make a native version of haproxy for Windows, > using some of the platform-specific features for network I/O. You're having strange hobbies in my opinion :-) > I've been using clang-cl to compile and it mostly works well. There are a > lot of warnings generated in the code that fall into two categories: > > 1. General warnings that are probably the difference between clang being > stricter than gcc. Do you have many of them? Some users (at least the ones on FreeBSD ans OSX I guess) commonly use clang if my understanding is correct, and a quick check at our CI on builds using clang doesn't indicate any warning, so they might be partially related to the platform. > 2. Size difference between unsigned long on LLP64 (Windows) vs Unix (mostly > LP64, i guess). Oh yes this is by far the real issue with this platform: there is no standard type which is the size of a native register on all archs. You have to switch to size_t and consorts to work around this mess :-/ > The Windows stuff is a long way from a pull request yet, but if there is > interest I can send a pull request on github for just the common code I > have touched. It would be nice to have it upstreamed so I can concentrate > on just the gnarly bits. > > Please let me know (please CC me as I'm not yet subscribed to this list) So I'm not sure there is any particular interest given that it's not frequent to see that platform used on infrastructure components, and even a number of developers who have the choice tend to move away from it. However if the changes are minimal and non-intrusive, I'm not against getting them merged, if at least this eases your task next time you have to work on it. But I really have strong doubts regarding the type "long" which is broken there :-/ Also do not bother sending a PR, they're automatically closed. We prefer reviewable patches here on the ML. If there is a place where your code is viewable (even if dirty, don't worry, we all know how it is during porting) please just send a link, I'm curious to see how you managed to work around all those longs we're using. Just a question, do you have a compelling use case or did you do it only for fun ? Thank, Willy
haproxy, Windows, pull requests
hi, I've taken up a hobby task to make a native version of haproxy for Windows, using some of the platform-specific features for network I/O. I've been using clang-cl to compile and it mostly works well. There are a lot of warnings generated in the code that fall into two categories: 1. General warnings that are probably the difference between clang being stricter than gcc. 2. Size difference between unsigned long on LLP64 (Windows) vs Unix (mostly LP64, i guess). The Windows stuff is a long way from a pull request yet, but if there is interest I can send a pull request on github for just the common code I have touched. It would be nice to have it upstreamed so I can concentrate on just the gnarly bits. Please let me know (please CC me as I'm not yet subscribed to this list) thanks, -amol
