[tor-dev] building from source in a 64-bit windows environment..

[not me]

> Neither of these is true.

I could accept it's been a while.

> For one, Tor builds fine for me, with no warnings, for me under
> mingw64.   (I just tried it out to be sure, and used
> --enable-gcc-warnings to make sure I got all the weird fiddly
> warnings.)

I've not attempted with mingw for stated reasons. I'd have to question
gcc's warnings here, there's lots of size_t to signed int, or size_t
to uint16_t, or intptr_t to signed int, size_t to ssize_t, comparisons
between signed and unsigned, etc. Without argument a lot/most/whatever
are going to be benign, but with the volume of them and especially
instances where a pointer is being converted to an integer type makes
me think that at least some of them should be checked out and modified
if necessary. I'd guess that whatever the flags being passed, they're
actually not turning on some/many of gcc's warnings, but that's just a
guess.

> For the other, there's been an nmakefile for ages now.   That would
> seem to suggest that an msvc build has happened at least once.  It
> doesn't get updated too often, because msvc users don't test or send
> patches very often.

Indeed, go ahead and pop it open with msvc2012 and give it a shot.

> I bet you didn't edit src/win32/orconfig.h  ? Ordinarily, autoconf
> would be setting all the types right for you, but if it isn't there,
> you need those defines to be right for your platform.  For example, I
>bet that you've still got a #define SIZEOF_VOID_P 4 in there.

I did, the first thing I had to fix was all the typedef's for
intptr_t, however no, I haven't taken the time/initiative to go
through the entire file and you're almost certainly correct about
defines for void*.

> A patch to add an appropriate set of #ifdefs for win64 to
> src/win32/orconfig.h would be welcome.

I spent some time going through the specs last night and it looks like
just writing my own code is the easiest path, all I actually need is
client code.

> strncpy and vsnprinf and fileno aren't deprecated in my world.

posix vs. ISO

> That said, I would sure not object to somebody doing the requisite
> work to make Tor build happily and warning-free under msvc and under
> msvc for windows 64, and I'd be happy to take whatever clean patches
> come out of this.

I believe this is going to also be a msvc 2010/2008 vs msvc 2012
thing, for instance as I said, they finally decided that having a
stdint header was a good idea and it seems like some warnings are now
errors and they've generally cleaned up their conformance a lot. This
last part is a guess of mine and not really based on any large volume
of methodical study, and of course could be wrong.

> (I keep saying "clean" to emphasize that I'm *not* going to take
> patches that break other operating systems or compilers or older
> versions of msvc, and I'm *not* going to take patches that litter the
> code with #ifdefs in every single function that makes a syscall. I
> shouldn't have to say this, but I've gotten a lot of patches like that
> over the years.)

I totally agree with this sentiment, although I giggled a little at
the ifdef's thing. Either way, as I said, the amount of work required
exceeds what I at least perceive writing a some simple client
functionality of my own would be. What I need is libonionrouter, not
so much the entire tor package. all I really need to do is talk
to/parse data from directories and build a circuit. I'm fairly
positive the amount of code requisite there is far less than reading
through/understanding and modifying hundreds/thousands? of lines of
code.  Best of luck with everything.



On Sat, May 18, 2013 at 10:43 AM, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Fri, May 17, 2013 at 10:07 PM, not me <anemenja at gmail.com> wrote:
>> Hi,
>>
>> It seems fairly self-evident that tor hasn't been build for 64-bit
>> windows and questionable whether it's ever been built in an
>> environment that doesn't utilize mingw.
>
> Neither of these is true.
>
> For one, Tor builds fine for me, with no warnings, for me under
> mingw64.   (I just tried it out to be sure, and used
> --enable-gcc-warnings to make sure I got all the weird fiddly
> warnings.)
>
> For the other, there's been an nmakefile for ages now.   That would
> seem to suggest that an msvc build has happened at least once.  It
> doesn't get updated too often, because msvc users don't test or send
> patches very often.
>
>>  There are literally hundreds
>> of thousands of warnings about integer truncation, at least some of
>> which seem somewhat problematic (64-bit pointer being stored in a
>> 32-bit integer (why?! why?!)),
>
> I bet you didn't edit src/win32/orconfig.h  ? Ordinarily, autoconf
> would be setting all the types right for you, but if it isn't there,
> you need those defines to be right for your platform.  For example, I
> bet that you've still got a #define SIZEOF_VOID_P 4 in there.
>
> A patch to add an appropriate set of #ifdefs for win64 to
> src/win32/orconfig.h would be welcome.
>
>>a small amount of signed/unsigned
>> comparisons or sign extensions,
>
> Those I'd like to fix, if they turn out to be real once the orconfig.h
> issues are fixed.
>
>> and a bunch of calls to functions
>> without including the proper header files or using the correct
>> function name ('open()' vs '_open()' without including io.h) and so
>> on.
>
> Clean patches would be welcome here.
>
>> This of course is ignoring all the calls to
>> str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since
>> deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC
>> finally including a stdint header (cstdint) and typedef's for intptr_t
>> not producing the right size primitive, etc.
>
> strncpy and vsnprinf and fileno aren't deprecated in my world.
>
> That said, I would sure not object to somebody doing the requisite
> work to make Tor build happily and warning-free under msvc and under
> msvc for windows 64, and I'd be happy to take whatever clean patches
> come out of this.
>
> (I keep saying "clean" to emphasize that I'm *not* going to take
> patches that break other operating systems or compilers or older
> versions of msvc, and I'm *not* going to take patches that litter the
> code with #ifdefs in every single function that makes a syscall. I
> shouldn't have to say this, but I've gotten a lot of patches like that
> over the years.)
>
> peace,
> --
> Nick
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev