> $ 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
> 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.
21 matches
Mail list logo
