[Fixed][Sketcher] windows build fails (conda)

[GeneFC]

the issue occurs only with current master, not with 0.19.3.

I am using the current master, of course. The "19.29.30139" number is the compiler version.

I just compiled again late yesterday, FreeCAD version 0.20.27371. Again, no problems at all.

OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.27371 (Git)
Build type: Release
Branch: Master
Hash: cfdf334b7f45b6ac0d6432890b1a9c5792ddaaa5
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United States (en_US)

Gene

[looo]

the issue occurs only with current master, not with 0.19.3

Of course. It's all about this class https://github.com/FreeCAD/FreeCAD/blob ... /GeoEnum.h that has been added last month.

I would have assumed that it's a compiler bug because it's working with so many compilers and it's perfectly valid C++ code. But now that Gene said he uses the exact same compiler version and for him it works then I guess something must be wrong with the object files from a previous build.

conda does a full rebuild, no caching.

Not using a cache is not the same as doing a clean rebuild. So, let me rephrase the question: are you sure that between two builds all object files (*.obj) are deleted?

I am pretty sure there are no .obj files stored. It's an azure pipeline. download source, build FreeCAD, create the package, upload the package.
Build logs are here:
https://dev.azure.com/sppedflyer/feedst ... 49ace9e213

[wmayer]

I am pretty sure there are no .obj files stored. It's an azure pipeline. download source, build FreeCAD, create the package, upload the package.
Build logs are here:

The original code from Abdullah didn't work on Windows and led exactly to the same linking errors you have posted. In order to get rid of them after I have changed the code I had to rebuild the Sketcher module from scratch because many object files still contained the extra definitions of the GeoElementId.

That's why I assume that there is still a leftover of them.

Btw, for the fix I had to add the keyword inline and this is another bug in MSVC because the C++ standard says that constexpr implicitly is inline.

[chennes]

Right, now I recall, that was the issue that forced me to rebuild as well. Azure Devops does indeed support caching, but I don't have access to your pipeline to see what sort you have enabled/disabled. You might have a look at these docs and see if they give you a hint.

[looo]

Right, now I recall, that was the issue that forced me to rebuild as well. Azure Devops does indeed support caching, but I don't have access to your pipeline to see what sort you have enabled/disabled. You might have a look at these docs and see if they give you a hint.

I really don't think that there are any stored files. Also when building locally conda always creates a new directory for the build process. Anyway, I try to build freecad now on my machine to check.

edit: same issue when building locally.

[noah]

https://dev.azure.com/sppedflyer/feedst ... _a=summary indicates that:

- the last successful pipeline is #20211221.1 +=1 (details: https://dev.azure.com/sppedflyer/feedst ... ew=results)
- the first broken Windows build is #20220104.1 +=1 (details: https://dev.azure.com/sppedflyer/feedst ... ew=results)

I didn't look at the build process so I'm just going to make an assumption that the latest master branch is fetched at the time of the build. So let's assume https://github.com/FreeCAD/FreeCAD/commit/dede24d5 is a known good commit since it went into master before Dec 21st according to git --no-pager log --first-parent --graph --since '2021-12-20'.

To limit the search scope I'm just going to pick a random commit such as https://github.com/FreeCAD/FreeCAD/commit/472c09cd from around the time of the first failed build on Tuesday Jan 4th. (Assuming that builds happen every Sunday, even during Christmas, then maybe an earlier commit such as https://github.com/FreeCAD/FreeCAD/commit/8bf59d77 from Wednesday, Dec 28th would be better).

Perhaps these commits could be used as starting points for bisecting the problematic commit, assuming the rest of the build environment (e.g. dependencies) are stable?

The list of commits that went in during this time:

- https://github.com/FreeCAD/FreeCAD/comp ... ..472c09cd

If you're good at spotting candidates to investigate further from commit messages alone, try:

Code: Select all

git --no-pager  log --oneline dede24d5...472c09cd

..or with filenames (to identify changes to e.g. cmake or sketcher related files):

Code: Select all

git --no-pager  log --oneline --stat dede24d5...472c09cd

This piqued my interest as I noticed that the first commit (from Dec 25th) in https://github.com/FreeCAD/FreeCAD/pull/5257 mentions "translation unit" and touches the identifiers that the linker complains about.

I don't have access to a Windows machine so I'll just leave this here and hope for the best.

[looo]

https://dev.azure.com/sppedflyer/feedst ... _a=summary indicates that:

- the last successful pipeline is #20211221.1 +=1 (details: https://dev.azure.com/sppedflyer/feedst ... ew=results)
- the first broken Windows build is #20220104.1 +=1 (details: https://dev.azure.com/sppedflyer/feedst ... ew=results)

I didn't look at the build process so I'm just going to make an assumption that the latest master branch is fetched at the time of the build. So let's assume https://github.com/FreeCAD/FreeCAD/commit/dede24d5 is a known good commit since it went into master before Dec 21st according to git --no-pager log --first-parent --graph --since '2021-12-20'.

To limit the search scope I'm just going to pick a random commit such as https://github.com/FreeCAD/FreeCAD/commit/472c09cd from around the time of the first failed build on Tuesday Jan 4th. (Assuming that builds happen every Sunday, even during Christmas, then maybe an earlier commit such as https://github.com/FreeCAD/FreeCAD/commit/8bf59d77 from Wednesday, Dec 28th would be better).

Perhaps these commits could be used as starting points for bisecting the problematic commit, assuming the rest of the build environment (e.g. dependencies) are stable?

The list of commits that went in during this time:

- https://github.com/FreeCAD/FreeCAD/comp ... ..472c09cd

If you're good at spotting candidates to investigate further from commit messages alone, try:

Code: Select all

git --no-pager  log --oneline dede24d5...472c09cd

..or with filenames (to identify changes to e.g. cmake or sketcher related files):

Code: Select all

git --no-pager  log --oneline --stat dede24d5...472c09cd

This piqued my interest as I noticed that the first commit (from Dec 25th) in https://github.com/FreeCAD/FreeCAD/pull/5257 mentions "translation unit" and touches the identifiers that the linker complains about.

I don't have access to a Windows machine so I'll just leave this here and hope for the best.

Thanks for your effort. As much as I would like to solve this somehow, I have to admit, that I don't have the capabilities to do so. So for now the windows-conda builds are broken.

one more question:
which c++ standart do you use @channes, @wmayer, @GeneFC

Code: Select all

-- Standard:            Requires C++17

[wmayer]

We all use C++17 as this is the minimum version for FreeCAD v0.20.

In order to fix the issue then it's probably best to ping Abdullah again to adjust the code. Will it be possible for you to test code changes locally to see if this fixes the issue before committing it?

[looo]

We all use C++17 as this is the minimum version for FreeCAD v0.20.

In order to fix the issue then it's probably best to ping Abdullah again to adjust the code. Will it be possible for you to test code changes locally to see if this fixes the issue before committing it?

I can test locally but I have to setup a testing environment. Shouldn't be a big problem with "conda debug" (hopefully).

[abdullah]

We all use C++17 as this is the minimum version for FreeCAD v0.20.

In order to fix the issue then it's probably best to ping Abdullah again to adjust the code. Will it be possible for you to test code changes locally to see if this fixes the issue before committing it?

I believe the code to be c++17 compliant and I do not see how the code may result in this linker error. Not understanding it, makes it difficult to see which tweak of the code may help.

Following the route of MSVC bug, I have searched for the link error and the MSVC version to see if there was some known bug or special behaviour. I have found nothing (not in MSVC documentation, Stackoverflow, or googling around).

I am not familiar with MSVC. If we need to use MSVC in Azure (i.e. if clang is not an option), then I think we should try to answer the question of why it works for Gene and it does not work in Azure, if the code is the same.

I make myself these questions:
- Are there different flags passed to the compiler or the linker in Azure and Gene? Could we compare the flags used?
- Is there maybe a flag causing to just pick one of the duplicated symbols if there are duplicated ones? (I mention this last because, when it works (Gene), either there are not duplicated symbols or the linker must silently pick one).
- Can we use a different version of MSVC in Azure?

Sorry I am not being useful.