Hi Bruno,
Thanks for reply.
>> 1. frexp.c is not needed, as Visual Studio already provides frexp()
>> function via system libraries.
...
>Do you have data that shows that MSVC14's frexp() behaves better than the one
>in MSVC 9?
Do you have advice how I can check this quickly? Visual Stu
Hi Kees,
> 1. frexp.c is not needed, as Visual Studio already provides frexp()
> function via system libraries.
The configure log says:
checking whether frexp works... guessing no
...
checking whether frexpl works... guessing no
Why "guessing"? Apparently AC_RUN_IFELSE refuses to run the
t
>> 1. frexp.c is not needed, as Visual Studio already provides frexp()
>> function via system libraries.
>But probably with bugs. And even if it is not needed on your platform,
>it is part of the tarball to replace broken frexp() on systems where it
>is buggy. Part of configure determines
Hi Bruno,
>Most of these troubles should go away if you use the 'compile' and 'ar-lib'
>auxiliary scripts, as described in section 2 of
>http://git.savannah.gnu.org/gitweb/?p=gperf.git;a=blob_plain;f=README.windows
>These instructions were tested with GNU gperf and a couple of other GNU
>packages
>gnulib has been updated to work with this platform on 2016-12-13, see
>http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=5506db6b006274762bf5ea1d23feb7a9801529c8
>Eric Blake replied:
>> If you can help port gnulib to the newer visual studio 2015, I'm sure
>> patches are welcome.
>> ...
>Are the mentioned patches in the snapshot that was provided by Jim?
>In any case, I will check today. Thanks for prompt replies.
>If you like, I can share some additional changes I've made, e.g. Visual Studio
>does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in
>macro
On 02/07/2017 08:13 AM, Kees Dekker wrote:
> Based on what I found today: the changes at low-level stdio in the FILE
> struct are now complable (I did not have yet a chance to let pass gzip our
> own internal tests, will do so later today or tomorrow).
> But still some things are incorrect:
>
>
Hello Kees,
> If you like, I can share some additional changes I've made, e.g. Visual Studio
> does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in
> macro), a workaround for missing #include_next directive (which is not
> supported by Visual Studio), a struct that is in
Kees Dekker wrote:
> > I tried to compile gzip with visual studio 2015. Unfortunately, a few files
> > could not be ported. Microsoft has redesigned the core CRT which affects
> > the visibility of (hidden/internals) of e.g. the FILE type. None of the
> > internals of the FILE type is not visible a
[adding gnulib]
On 02/06/2017 09:28 AM, Kees Dekker wrote:
> Hi,
>
> I tried to compile gzip with visual studio 2015. Unfortunately, a few files
> could not be ported. Microsoft has redesigned the core CRT which affects the
> visibility of (hidden/internals) of e.g. the FILE type. None of the i
10 matches
Mail list logo
