On 12/9/20 8:50 PM, Dan Wilcox wrote:
Howdy all,
As quickly discussed on GitHub, there are a couple bugs which may warrant a
0.51-4 release.
In addition, here is a little list of things I think would be good fixes to
have:
windows: save-to-/tmp/foo.wav bug
+1
networking & libpd:
Before anyone looks further into the *details* ie. compiler flags, the
configure overview output gives us a clue:
> configure:
>
>pd 0.51.3 is now configured
>
>Platform: Unknown
Clearly, configure failed and it never set the platform. The platform-specific
/ host checks
Howdy all,
As quickly discussed on GitHub, there are a couple bugs which may warrant a
0.51-4 release.
In addition, here is a little list of things I think would be good fixes to
have:
windows: save-to-/tmp/foo.wav bug
networking & libpd: getaddrinfo() rejects dual stack socket settings on
On Wed, 9 Dec 2020 at 16:03, Christof Ressi wrote:
> These paths are wrong. The toolchain should be in the "mingw32" resp.
> "mingw64" folder.
>
> Just a quick check: did you follow all the steps in
> https://github.com/pure-data/pure-data/blob/master/INSTALL.txt?
>
Yes, in May, and in October,
I've seen these compiler defining constants come and go and mutate
over the decades
Nah, _WIN32 and _WIN64 have always been the standard definitions. _WIN32
is always defined, and _WIN64 is additionally defined for 64-bit
targets. But some toolchains used their own non-standard definitions
Also note/try:
$ ./autogen.sh
$ ./configure
$ make app
I'd never used:
$ make all
--
Mensaje telepatico asistido por maquinas.
On 12/9/2020 11:53 AM, Christof Ressi wrote:
indicating that _WIN32 is not defined.
So if I instead build with CFLAGS=-D_WIN32, I get a different
indicating that _WIN32 is not defined.
So if I instead build with CFLAGS=-D_WIN32, I get a different set of
errors while building s_inter.c
If "_WIN32" is not defined by the compiler, something is going very wrong...
usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld:
