Windows Builds (LP 12.5.4 and Conda) Possible Surplus Dlls

[Syres]

Has a user requested that certain Dlls be retained in the Windows builds, specially those listed below?

Code: Select all

libgfortan-3.dll
libssp-0.dll
libstdc++-6.dll
libvtv_stubs-0.dll
libvtv-0.dll
libgomp-1.dll
libgomp-plugin-host_nonshm-1.dll
libquadmath-0.dll
libatomic-1.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll

The reason this has been raised is they weren't in the old LP 12.1.6 builds and there was never an issue running the Dependency Check in the CfdOF Wb. The Conda builds haven't been able to verify the Hisa and CfMesh versions for some months now but it has become apparent that the issue has been affecting the LP 12.5.4 builds also. To me the Dlls listed above left over from the compiling process and aren't actually used by FreeCAD during runtime. See https://forum.freecadweb.org/viewtopic. ... 39#p514308 for further info.

I've been carrying out some fairly basic but regularly used functions in FreeCAD on both recent builds and haven't got any errors or untoward behavior having deleted the Dlls from the bin folder. So if it's determined that they aren't required could they please be deleted from the build routines?

ping

ping

[sgrogan]

The reason this has been raised

I have been away, I will look.

[sgrogan]

I've been carrying out some fairly basic but regularly used functions in FreeCAD on both recent builds and haven't got any errors or untoward behavior having deleted the Dlls from the bin folder. So if it's determined that they aren't required could they please be deleted from the build routines?

I posted a new LP build, manually removing these .dll's https://github.com/FreeCAD/FreeCAD-Bund ... kly-builds

I don't see these .dll's in my local, native mini-Conda installation (PY3.8.10)
I do see them in the Conda bundle from the above link.

The difference between my local Conda and the bundle is I haven't installed all the extras.
https://github.com/FreeCAD/FreeCAD-Bund ... dle.bat#L8

I suspect one of these extras pulls in the dependency .dll's and that extra package is in both the LP and Conda versions.

I'll try to install these extras one by one to see where it comes from.
@Syres, I know you have been "bull dogging" this for quite some time. Thanks!
I think you've given me the thread to pull. Hopefully we can figure this out finally.

[Syres]

I posted a new LP build, manually removing these .dll's https://github.com/FreeCAD/FreeCAD-Bund ... kly-builds

I'll give it a thorough test, cheers and welcome back!!

[bernd]

a few of them are needed by CalculiX ... https://forum.freecadweb.org/viewtopic.php?f=42&t=61029 would be cool if you could put them back chris.


cheers bernd

[sgrogan]

I'll give it a thorough test, cheers and welcome back!!

a few of them are needed by CalculiX ... https://forum.freecadweb.org/viewtopic.php?f=42&t=61029 would be cool if you could put them back chris.

@Syres, do these kill the CfdOF WB? Does CfdOF Wb use Calculix as well, or is the clash a cross dependency to some other package?
We have another (thread) clue to pull and solve this.
I think a clue is that the conflicts must come from Mysys/cygwin compilation.

[bernd]

CfdOF Wb does not use Calculix at all.

[Syres]

@Syres, do these kill the CfdOF WB? Does CfdOF Wb use Calculix as well, or is the clash a cross dependency to some other package?
We have another (thread) clue to pull and solve this.
I think a clue is that the conflicts must come from Mysys/cygwin compilation.

At present @oliveroxtoby has put a workaround in to copy the files libstdc++-6.dll and libgomp-1.dll from the directory <blueCFD directory>\msys64\mingw64\bin
into the directories <blueCFD directory\OpenFOAM-8\platforms\mingw_w64GccDPInt32Opt\bin and also <blueCFD directory>\ofuser-of8\platforms\mingw_w64GccDPInt32Opt\bin so it's not a show stopper. But, a long while ago I was in a similar situation with a production environment and workarounds like this can get forgotten and can bite when least desired.

I'm sure we can find a solution where both binaries can share a specific set of dll's but it's going to need me to carry out some rigorous testing and even if I can get a solution then it would need @bernd to sign off on it.

I'm prioritising some other work as it's impacting the core but I should have some decent quantity of time next week to look at this.

[bernd]

What does this mean? Does it mean Chris can not put back these dlls?

We should get back these dlls as soon as possible. CalculiX is the solver of FEM. Without CalculiX FEM does not work at all.

[Syres]

What does this mean? Does it mean Chris can not put back these dlls?

Yes, the Dll's should be put back hence the statement regarding the workaround in place, sorry for not being clearer.