VS2017 LNK1104 cannot open <library>.lib with JUCE 6.1.3+

Development
1

Hi,

Currently we are transitioning our codebase from JUCE 5 to JUCE 6. I’m responsible for migrating ongoing project to be updated to the latest version of JUCE. Up until JUCE 6.1.2 our current project is compiling just fine, with some warning of deprecated method here and there.

Recently i’ve updated to JUCE 6.1.4, and now the current project failed to compile with Visual Studio 2017. The error message was

LNK1104 : Cannot open file .lib

The external library which cannot be opened was OpenSSL binaries. Nothing changed in the code itself nor the flags on Projucer Preprocessor Definitions. Everything was exactly the same, except for JUCE version.

I reverted back to 6.1.3 the problem persists, with the same error message. But with 6.1.2, everything compiled just as expected in Visual Studio 2017.

Audio Plug-Ins Hello World project with 6.1.4 is compiling fine too with our current machines, the problem arise when including external libraries which we rely on.

Any idea how to resolve this issue?

Thanks

EDIT : VS2017 built solution with JUCE 6.1.2 (with the inclusion of the troublesome external library) even successfully compiled with VS2022 & MSVC v143.

2

I guess the combined changes from

and

don’t work for your project.

What do you have in the “External Libraries to Link” field(s)?

3

These are the fields that causing the errors

01
01780×116 7.16 KB

02
02786×113 14 KB

I will check those links.

Thanks

4

Firstly, note that the format for the “External Libraries to Link” field is one-per-line. You should definitely insert a newline between the library names, and for forward-compatibility you should ideally avoid defining the full paths to the libraries here. I think the contents of the “External Libraries to Link” field should look like this:

libeay32MTd.lib
ssleay32MTd.lib

And then, the “Extra Library Search Paths” field on each exporter should contain the path to the libraries.

Does the build work if you remove the semicolons from the ends of the preprocessor definitions? I think that the problem likely stems from the semicolons being escaped in the project file. Unless you actually want the semicolons to be part of the preprocessor definitions, you should remove them.

1 Like
5

I rewrite all the fields as you suggested. And now it compiled with latest JUCE 6.1.4 and MSVC 2022 with MSVC v143.

Thank you very much!

1 Like
6

I’m having trouble with something similar, so let me ask in this thread.

In the project I’m developing, I’m relying on the name of the Configuration(ex.Debug/Release) to switch the referenced library.
Up to v6.1.2 of JUCE, I was able to get away with writing the following Visual Studio 2017 configuration for Projucer.

image
image1144×115 9.3 KB

However, when I update my JUCE version to 6.1.4, this doesn’t work.
I’ve seen this thread and understand why there is a difference, but I’m having a lot of trouble with this change.
How do I write this if I do NOT want to convert escape characters?

7

In my case, the External Libraries to Link field only contains the variable name to the referenced library. Here’s how i got it working
image

and in the Preprocessor Definition field, define the correspond variable name linked to which library (only the file name).
image

and as @reuk suggested, the path to its library (the actual directory which contains the lib files) written in Extra Library Search Paths
image

8

@bayu
Thanks for showing me your setting.

In the Preprocessor Definition field, I rewrote the library name for each configuration in Visual Studio, and it worked.
However, I think it would be easier and more maintainable to use Visual Studio macros.
The fix that automatically disables the macros is not good and I hope it will be improved. > @reuk
I’ve found people saying the same thing on the forum, so I’m sure there’s a good number of people who agree with me.

Anyway, thank you.

9

That’s true, sorry about that. I’ve now updated the Projucer so that libraries in the “External Libraries to Link” field will no longer be escaped:

This means that it is once again possible to use VS macros when specifying external libraries. Hopefully the new behaviour is intuitive. Please let us know if you encounter any new issues with the change.

1 Like