Trying to port an example project for a product that uses a static library for iOS 13.2. The library is an "SDK" with the headers and .a and built singularly for "ARM64 Release" for the iPad. The original project, written for iOS 8.1 with VS2017, simply used -llibSomething.a in the "Additional Options" field and that worked. When doing the same in VS2019, the mac reports back that the linker option is ignored and fails to include it in the command that actually builds the application resulting in missing symbols. For the C++ application settings, there are no express linker options in the property page for the project unless I'm missing something--I'm not a big visual studio or iOS person. I know the path to the SDK is correct, the project finds the headers and compiles the sources without any undefined symbols, it just won't seem to link in the library. The biggest issue is that this all has to be done with whatever Visual Studio has to offer. Am I missing a dialog where this reference is supposed to go or is there something in the project.pbxproj that I'm supposed to be modifying?
Wound up answering my own question:
Unload the project
Edit the project.pbxproj
In the XCBuildConfiguration area for your configuration, add an entry for OTHER_LDFLAGS = "-lSomething ";
The list is just space separated, same as on the command line
Related
I have problems building my code that is using static lib detours. I am trying to do an old basic CTF. For that I want to get into detours.
Whenever I try to build my .dll file I get an issue
LNK2019 unresolved external symbol _DetourTransactionBegin#0 referenced in function _DllMain#12
Now, I have built the detours library using 3 different version of the visual studio dev console.
I have tried firing 'vcvars32.bat' and then using nmake to build the library which was able to build it, but I get the above error during linking my .dll. I have also tried building it with 'vcvarsamd64_x86.bat' and then using nmake to build it which also was able to build the library, but I still get the same error as above during linking.
I have tried the usual stuff: the include folder for detours.h is added to C++/General/Additional Include Directories.
Under Linker/Additional Library Directories I added them as follows: "C:\temp\det_retry\lib.X64";"C:\temp\det_retry\lib.X86";%(AdditionalLibraryDirectories).
And also under Linker/Input/Additional Dependencies I have the following: detours.lib;%(AdditionalDependencies)
What am I missing here? This is a blocker for me for a couple of days and I am reiterating the same steps trying to figure out what's missing but I cannot see. I'd really appreciate the input.
I am sure I am using the newest version because I have downloaded (cloned) detours from the ms github page.
It appears your "Additional Library Directories" are setup incorrectly or contain invalid entries rather. They look like actual library file entries (i.e. pointing to some specific files) versus being only directories (e.g. "my/lib/path/for/my_project/"). Visual Studio's naming conventions are somewhat cryptic but they should be directory entries only. There should be an entry to whatever directory contains the detours.lib file (e.g. "MyProject/Libs/MSDetour" ... where MSDetour is a folder with the "detours.lib" in it) and then Visual Studio should find the library and link everything correctly.
As a side note, if you are using the Visual Studio developer console for building your project/solution you might want to look into CMake ... it is, in my opinion, significantly easier to work with (less "settings" digging) and maintain in the long-run.
I'm using Visual Studio 2013, with the 2012 toolset and I'm trying to split an win32 executable project up into an exe that consumes a dll that contains all the program logic. The end goal is to be able to create a seperate project for unit tests that can link against the new dll.
Now the old version of the project compiles absolutely fine and uses cryptlib.lib (thanks SVN!), but once I separated it out in to a dll with the program logic and the same project settings I get the following error when I attempt to build the dll:
Error 546 error LNK1104: cannot open file 'cryptopp.lib'
I have the directory that contains cryptlib.lib in my linker settings and I'm linking against it just as I did in the previous project settings. Based on the documentation it shouldn't be trying to link against cryptopp.lib because CRYPTOPP_DEFAULT_NO_DLL is defined in the preprocessor settings.
I also tried adding the directory that contains cryptopp.lib to the VC++ directory paths and I added cryptopp.lib to my linker settings, and it still gives me the same error. I don't want to use the dll version of cryptopp, but at this point I just need the thing to work.
All the projects are using the 2012 toolsets, and all are being compiled as win32 projects so I'm not sure where to go from here.
Well I figured out what was happening, if not why. For some reason the preprocessor definitions don't seem to be getting applied. If I put CRYPTOPP_DEFAULT_NO_DLL at the top of all the include files it works as expected.
Create a new solution with a C++ console command-line project
Create a new project, a C++ static library
Make the command-line project depend on the library
Make sure "Link Library Dependencies" is turned on in Configuration => Linker => General (it is by default)
Visual Studio will still not link the library.
How can I fix this? It worked in Visual Studio 2008.
This still works, but was changed in VS 2010:
"With VS2010, we stopped supporting project dependencies defining implicit references and we also introduced a new way of defining project dependencies at the project level. Since a project reference and a project dependency are close concepts, both applying to a project, it made sense to have them represented together, in a consistent way, in the project file. As you will see in the snippets below, the only difference between a project reference definition and a project dependency definition consists in metadata that defines the output assembly inclusion/exclusion into/from the main project link command line.
Although we did not remove the “Project Dependencies” dialog, we recommend defining new project dependencies via the “Framework and References” dialog. You need to set the “Reference Assembly Output” property in the property page UI to false for a project dependency and to true for a project reference."
Just right-click on the console project, select "Properties->Common Properties->Framework and References->Add New Reference" and add the static library project; also check that "Link Library Dependencies" is True on the right hand side. Seems to work for debug and release builds. You learn something new every day. ;)
They changed the UI for adding C++ project dependencies in VS2010, but oddly enough, without removing the old UI, or in any way indicating that it no longer works.
To create the dependency in VS2010, you need to use "Add New Reference" (can be found in project properties), and maybe also in the project's right-click menu (don't have VS here to check)
The old "Project Dependencies" dialog is basically broken now.
For MSVC 14 (2015 version) right-click on the project, then "Add->Reference..." and check all the needed dependencies.
Yes, it has changed somewhere between 2010 and 2015 versions. Fun!
And if you are looking to link a project that has resources in it - you need to specify the .res file directly in the list of linker input dependencies (project's properties dialog box) as it doesn't get picked up by the above configuration.
UPDATE
Still the same (new) behavior in MSVC 2017
I believe the old UI (dependencies) affects build order for Visual Studio, when building from within the IDE, for info. The new project configuration system embeds the references in each project file so that you can build from outside the IDE (whereas in previous versions, you could not, because you would not get automatic linking for dependencies, since dependencies were only done at the solution level).
There are also some issues with more complex projects in the new system; specifically, all resulting binary projects need to have explicit references to every dependent library to build correctly, whereas previously they could be effectively inherited from other dependent libraries. Same underlying cause, though.
I have migrated my VC6 application to VS2005, all my code got compiled with some changes and there is no compilation error.
But I am getting a linking error LNK1104.
LINK : fatal error LNK1104: cannot open file 'mfc42u.lib'
I have imported the dsw of VC6 in Visual Studio 2005, not sure from where it is still referring to the mfc42u.lib (I assume its library of VC6).
Please guide me how to get rid of this error.
This library is referred from Linker section of your project settings, specifically "Additional libraries" or something like this (do not remember the name of the setting exactly) - there are libraries needed to be linked with listed there. So just replace the mfc42u.lib with mfc8u.lib or whatever is the relevant version of mfc installed with your VS distribution there.
probably your linker settings aren't set properly. Go to Project Settings->Configuration->General->Use MFC Libraries and make sure the value is set to 'Use MFC in a shared library'. If you are able to build properly, then you can change it back to 'Static' to use the new library.
We recently converted a C++ project from Visual Studio 6 to Visual Studio 8. Everything went well until we reached the compilation of a project who put all the static libraries inside one big static library. By default after the conversion between the two version of projects the project didn't do anything (no big static library was created, it only said that the project was up-to-date).
We found a working solution by adding a dummy (empty) file to the project (it had no other files before, in the Visual Studio 6 solution). Everything went well and we managed to compile the project with the new development environment (Visual Studio 8).
My question is: Is there any other way to do this, without dummy files added to the project?
Thanks in advance for your responses
You can use the method described in the answer by nobugz also with multiple configurations and different directories for debug and release input libs. Just add all input libs, debug and release, and use "exclude from build". In the debug configuration exclude all release input libs from the build, in the release configuration exclude all debug input libs.