sorry for spamming, but I think this SO question and the given answers shed
some more light on the issue:
https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application
TL;DR: programs built with VS can either link statically against the MSVCRT or
they have to
to sum it up: msvcrt.dll is always present on the system anyway, so there's no
need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I
would consider this a bug.
> Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr
> Von: "Christof Ressi"
> An: "Miller Puckette"
> Cc:
> I will try to find out if any of the old extended externals actually
> needs these dlls. Probably msvcrt.dll comes from the Msys1 era.
Thanks for testing!
just to make sure: *all* Pd externals compiled with MinGW have a dependency on
MSVCRT.DLL but they use only C functions and it doesn't
P.S. this would at least provide compatibility with old externs; then, if
new externs all were compiled staticly-linked to their own libc versions,
everybody might be able to get along together.
Actually, I do wonder about malloc() - how can different versions of that
coexist? It makes my head
On 1/23/19 12:42 AM, Miller Puckette wrote:
> I bet most externs use one or another thing from msvcr*dll. String
> functions, malloc, etc...
i guess we should wait for lucas to finish his tests.
>
> Here's an idea, what if I stuck msvcr*dll in a separate directory and
> called SetDllDirectory
I bet most externs use one or another thing from msvcr*dll. String
functions, malloc, etc...
Here's an idea, what if I stuck msvcr*dll in a separate directory and
called SetDllDirectory another time in s_loader.c to allow externs to find it
if they need it?
M
On Wed, Jan 23, 2019 at
On 1/22/19 11:36 PM, Miller Puckette wrote:
> Would this mean that anyone shipping a binary external for Windows would
> have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
> Sounds like a nightmare to me.
but i think that's really the only sane way.
unless you can
On 1/22/19, Miller Puckette wrote:
> I don't understand the issues yet... in particular, since pdlibbuilder uses
> mingw on Windows, how does it work with Pd if mingw and msvcr*dll aren't
> compatible? Is pdlibbuilder/mingw statically linking in its own msvcr*?
For Windows pdlibbuilder
> Is pdlibbuilder/mingw statically linking in its own msvcr*?
Yes. -->
https://github.com/pure-data/pd-lib-builder/blob/master/Makefile.pdlibbuilder#L638
I guess you don't want to hear the nightmares of the C-runtimes that are
needed to ship if compiling with MSVS. (latest VS compiled stuff
Would this mean that anyone shipping a binary external for Windows would
have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
Sounds like a nightmare to me.
I don't understand the issues yet... in particular, since pdlibbuilder uses
mingw on Windows, how does it work with
I also agree.
I will try to find out if any of the old extended externals actually
needs these dlls. Probably msvcrt.dll comes from the Msys1 era.
I'll check ASAP with the list of old externals (attached).
Mensaje telepatico asistido por maquinas.
On 1/22/2019 6:51 PM, Christof Ressi wrote:
>
I agree and I've already suggested this:
https://lists.puredata.info/pipermail/pd-dev/2018-09/021721.html
BTW, I got linker errors because of msvcrt.dll when I compiled Dan's
pdfontloader. this left me scratching my head for quite a while. removing the
DLL solved the problem.
hi,
TL;DR: i'd like to suggest to remove the "msvcr90.dll" and " msvcrt.dll"
files from the pd\bin\ folder of all (future) windows releases.
rationale
=
# usage by Pd
first of all, these files are not used by Pd at all.
they are only provided as a courtesy for externals that happen to
13 matches
Mail list logo
