> $ deken find --arch "Windows-*-*" | sed -n -e 's|^.*\bURL:
> \(.*(Windows-.*\)|\1|p' | sort -u
>
> gives me the attached list (including those you already scanned).
I found missing pkgs from your list but I got a complete one using deken
(cancelling a download a binking prompt appears on the
On 1/25/19 12:13 PM, Lucas Cordiviola wrote:
> I've finished scanning all the packages from "deken_w32_filled_2.txt"
> attached earlier on this thread which covers all Deken as of july 2016.
> No traces of "msvcr90.dll".
>
> @IOhannes:
> Can you generate a new .txt with all w32 pkgs?
>
> I'll
I've finished scanning all the packages from "deken_w32_filled_2.txt"
attached earlier on this thread which covers all Deken as of july 2016.
No traces of "msvcr90.dll".
@IOhannes:
Can you generate a new .txt with all w32 pkgs?
I'll gladly scan the rest.
:)
Mensaje telepatico asistido por
On 24.01.19 08:25, Lucas Cordiviola wrote:
> Few externals are compiled with VS
where do you get that metric from?
Pd-extended compiled everything with mingw, so *there* was indeed no VS
involved. this spilled over to the packages available via deken.
but i figure that there is quite a number
t;
>>
>> Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr
>> Von: "Christof Ressi" <mailto:christof.re...@gmx.at>
>> An: pd-dev <mailto:pd-dev@lists.iem.at>
>> Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>
>> to sum it up: msvc
/win
>
> 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: &
On 1/23/19, Christof Ressi wrote:
> msvcrt.dll is very old and was declared a private system library which
> applications should not link against (didn't know that!), but MinGW does
> anyway.
This SO thread may clarify why MinGW does depend on msvcrt.dll:
On 1/23/19, Miller Puckette wrote:
> I bet most externs use one or another thing from msvcr*dll. String
> functions, malloc, etc...
I've always naively assumed that MinGW's libgcc and libstdc++ are a
full replacement for MS standard libs (which notably do not include
pthread). Pd-extended
christof.re...@gmx.at>
An: pd-dev <mailto:pd-dev@lists.iem.at>
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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 consid
uar 2019 um 01:54 Uhr
> > Von: "Christof Ressi"
> > An: "Miller Puckette"
> > Cc: pd-dev@lists.iem.at
> > Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
> >
> > @Miller:
> >
> > neither Pd nor any externals
Puckette"
> Cc: pd-dev@lists.iem.at
> Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>
> @Miller:
>
> neither Pd nor any externals built with MinGW (basically every external using
> pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or
&g
nstag, 22. Januar 2019 um 23:22 Uhr
> Von: "Lucas Cordiviola"
> An: "Christof Ressi" , pd-dev
> Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>
> I also agree.
>
> I will try to find out if any of the old extended externals actually
> needs
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
>> pdfontloader. this left me scratching my head for quite a while. removing
>> the DLL solved the problem.
>> https://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
>>
>> Christof
>>
>>> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
>&
> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
> > Von: "IOhannes m zm??lnig"
> > An: "PureData developer's list"
> > Betreff: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
> >
> > hi,
> >
> > TL;DR: i'd like to suggest to re
e problem.
> https://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
>
> Christof
>
>> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
>> Von: "IOhannes m zmölnig"
>> An: "PureData developer's list"
>> Betreff: [PD-dev] removi
://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
Christof
> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
> Von: "IOhannes m zmölnig"
> An: "PureData developer's list"
> Betreff: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>
> hi,
>
> TL;DR: i'
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
22 matches
Mail list logo
