Linker problem in Visual Studio

Windows
1

I am posting this as a new topic, because it is a new issue:

I have spend thelast three days researching a problem on Windows. The linker would take hours to build a project that took him minutes to link. Now I have found that this caused by the external libraries that are included in the project file for building the SharedCode library, which is redundant, because they are included in project file for the binary. It looks like it causes the linker a lot of time to process the redundancy.

I have now removed the external dependencies and the resource file from the SharedCode project and now, I got a Windows project I can work with. It is unfortunate though, because we use Projucer heavily and rely on the ability to generate Windows projects for the build server, which means we hardly have to leave our primary development platform, which is Mac OS.

With this behavior, we are forced to manually post process the WIndows project files.

3 Likes
2

Yes, this has been an issue for some time - it was raised when this was first introduced but nothing has happened about it. I think at the time I was the only voice, so maybe if there are more people raising awareness it might get changed.

I just go into the shared project setting and remove the libraries from the librarian settings after an update in projucer, but it would be nice not to have to do this.

In the past it was also suggested to change the LTO settings but this never had any effect for me, though this may have changed and I haven’t tried this for some time.

3

I assume, that it has not affected Roli developers that much, because they don’t rely on external libraries that much. I don’t know, why it is has become a problem now. Maybe changes in the latest Mircrosoft tools add to the problem as well.

4

it was changes made to the way projects were organised a few months ago.

5

If patching and re-building Projucer is a possibility for you, you should try to apply the following diff:

diff --git a/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h b/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
index e8033ded7..706a5e556 100644
--- a/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
+++ b/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
@@ -638,6 +638,7 @@ public:
                     bsc->createNewChildElement ("OutputFile")->addTextElement (getOwner().getIntDirFile (config, config.getOutputFilename (".bsc", true)));
                 }

+                if (type != SharedCodeTarget)
                 {
                     auto* lib = group->createNewChildElement ("Lib");

I hope this helps.

2 Likes
6

This fixes the issue with the dependencies, now I need to find a way to suppress the inclusion of resources.rc in the SharedCode project. I have spend some time tracing the Projucer code, but I would not find the step, where it gets included in the project.

7 
diff --git a/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h b/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
index e8033ded7..67ebc3ba1 100644
--- a/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
+++ b/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_MSVC.h
@@ -701,7 +701,7 @@ public:
             if (otherFilesGroup->getFirstChildElement() != nullptr)
                 projectXml.addChildElement (otherFilesGroup.release());

-            if (getOwner().hasResourceFile())
+            if (getOwner().hasResourceFile() && type != SharedCodeTarget)
             {
                 auto* rcGroup = projectXml.createNewChildElement ("ItemGroup");
                 auto* e = rcGroup->createNewChildElement ("ResourceCompile");

should do the trick.

8

Thank you, that fixed that issue too. Now our workflow is restored. I hope the changes will make into the master branch at some point. I don’t fell good about patching Juce.

1 Like
9

There is another line, where this comparison needs to be added. To summarize, here are the three changes I made in jucer_ProjectExport_MSVC.h:

@@ -638,6 +638,7 @@ public:
                     bsc->createNewChildElement ("OutputFile")->addTextElement (getOwner().getIntDirFile (config, config.getOutputFilename (".bsc", true)));
                 }
 
+                if(type != SharedCodeTarget)
                 {
                     auto* lib = group->createNewChildElement ("Lib");
 
@@ -701,7 +702,7 @@ public:
             if (otherFilesGroup->getFirstChildElement() != nullptr)
                 projectXml.addChildElement (otherFilesGroup.release());
 
-            if (getOwner().hasResourceFile())
+            if (getOwner().hasResourceFile() && type != SharedCodeTarget)
             {
                 auto* rcGroup = projectXml.createNewChildElement ("ItemGroup");
                 auto* e = rcGroup->createNewChildElement ("ResourceCompile");
@@ -892,7 +893,7 @@ public:
             if (otherFilesGroup->getFirstChildElement() != nullptr)
                 filterXml.addChildElement (otherFilesGroup.release());
 
-            if (getOwner().hasResourceFile())
+                       if (getOwner().hasResourceFile() && type != SharedCodeTarget)
             {
                 auto* rcGroup = filterXml.createNewChildElement ("ItemGroup");
                 auto* e = rcGroup->createNewChildElement ("ResourceCompile");
1 Like
10

bump. any comments from the JUCE devs as to whether we can make this standard in Projucer - I’ve never understood the need to link extra libraries multiple times.

thx

1 Like
11

Yeah, I struggle with this issue also. With link-time optimization enabled, my SharedCode .lib file ends up around 3GB – completely unusable.

Aside from that, the character limit in the textEditor for the ‘additional include directories’ in the Projucer doesn’t fit all the directories I need to include, and I’ve had to develop some scripts to achieve this as a workaround.

12

No, we shouldn’t be linking to external libs or compiling the resources file when building the shared code target. I’ll get this fixed.

5 Likes
13

thankyou! :smiley: :heart:

14

Have you been able to do anything about it ? I can still see this behaviour in 5.3.2.

15

i’ve not seen this behaviour since they said it was addressed…

16

Are you sure? The commit is here and it made it’s way onto the master branch with the 5.3.2 update so the Projucer from the latest JUCE website download should have the fix in. Have you re-saved your project?

17

Ok, thanks. I can confirm this now. It must have been a mistake on my side.

I have one Projucer issue left, that forces me to manually fix the Mac project file.