I need to define compiler symbol (say MYSYMBOL) in Lazarus project options (Lazarus 2.0.2) and cannot find how to do it.
That is, I need an equivalent of
{$DEFINE MYSYMBOL}
defined in project options which I guess will be transformed into compiler option -dMYSYMBOL.
How to do it?
You will find the project settings for compiler options under Custom Options
Related
In my Xamarin.iOS project I need to reduce the assembly size (Apple's requirement for AppStore applications), and I need to turn on linker, setting the linker behavior either to "Link Framework SDKs only" or "Link All".
When I've selected "Link Framework SDKs only" in Linker behavior I get the compilation error upon building the project:
Can't resolve the reference 'System.Void System.Data.SqlClient.SqlCommandBuilder::DeriveParameters(System.Data.SqlClient.SqlCommand)',
referenced from the method 'System.Void DevExpress.Xpo.DB.MSSqlConnectionProvider::CommandBuilderDeriveParameters(System.Data.IDbCommand)'
in 'System.Data.SqlClient, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
To fix this issue all answers I have found recommendation to turn "Link All" option in the Linker behavior option.
When I've selected "Link All", the project compiles okay, but at the runtime I get system exception on the IoC Container code (type AAA does not implement the interface BBB), because I use reflection, and linker with "Link All" options affects the code with the reflection. And as far as I know this linker option (Link All) is not recommended for the projects where reflection is being used.
What options do I have at this point?
Linker configuration
I suspect your best option is to look at define a configuration file to tell the Linker what must be kept. There is a good set of documentation on Microsofts documentation site.
There are some other options but may not strictly apply in this case or you may wish to use a combination.
Preserve Attribute
You can provide extra definitions to the linker to ensure the type, methods and/or fields are not eliminated from your application. In your own code the preferred way is to use the [Preserve] custom attribute, as discussed in the Linking on iOS and Linking on Android guides.
Linking for each platform is certainly a possibility however I suspect that you want to preserve things in your shared project which is why I think the config file will be right for you.
This approach gives you the ability to define at varying levels (e.g. assembly or class level to keep everything or down to individual properties/methods, etc.).
Actually reference the bits you need kept
I dislike this option very much but some people find it quick and easy to either prove you can keep parts of the code or just accept it is a solution.
You essentially create a class of actual references to the methods/properties that you want to be kept.
public class LinkerPleaseInclude
{
public void Include(MyType arg)
{
arg.MethodIDontWantRemoved();
}
}
Note I have sourced some details from this site
There seem to a variety of questions like this one without any clear solution that is true for Xcode 7 (or even other versions of Xcode).
I have a version of GCC that I'd like Xcode to use when it compiles. It is not the standard GCC but customized for a different platform. I can specify and use this compiler fine in Eclipse, but would rather use Xcode. The Build Options only list LLVM and nothing else. When I try to add via "other" in that section, all I get is this empty popup:
What goes in this box? I would think that it should be no big deal for Xcode to simply use a GCC that I have available at a specific path on my system, but this appears to be quite complex.
Update: Apparently there is a supported mechanism for installing externally-provided tool chains in Xcode that I wasn't aware of. For example, one can download packages from swift.org that install alternative tool chain packages into /Library/Developer/Toolchains or ~/Library/Developer/Toolchains. Once one of those is installed, Xcode has a GUI option to switch the active tool chain.
There was a recent change to the Swift sources to include a script for building one's own custom tool chain from them.
If you view the Quick Help for that build setting (View > Utilities > Show Quick Help Inspector) or configure the build settings view to show setting names instead of titles (Editor > Show Setting Names), you'll see that that setting is GCC_VERSION.
If you look that up in the Build Settings Reference, you find:
GCC_VERSION
Description:
Numeric identifier. Identifies the GCC version to be used to compile
the target’s source files. When the target’s “System C rule” is set to
GCC System Version (instead of a specific version number), this build
setting is not available in Run Script build phases.
Values:
2.95.2
3.1
3.3
4.0
Default value:
GCC system version.
Specified in:
Project Info > Rules > “System C rule.”
Target Info > Rules > “System C rule.”
Affects:
GCC_VERSION_IDENTIFIER.
That's actually a bit out of date. It says it's specified by fiddling with a build rule (not setting) called the "System C rule". You used to change the version there but now there's a direct build setting for it.
Anyway, this probably doesn't help you do what you want to do. I doubt there's any value you could put in there that would do something useful, let alone use a third-party compiler.
However, the explanation does have a hint. It mentions the System C build rule. You could modify the build rules on the Build Rules tab of the target configuration screen. You can find the System C rule and press the button to copy it to your target, which will let you specify a custom script to process C files (including Objective-C and C++).
Implementing such a script is non-trivial. The inputs, expected outputs, and required behavior of the script are not well documented. There are various environment variables available for the use of such a script. Some are the build settings. You'll need to translate the relevant settings into compiler options. For example, translate the CLANG_WARN_BOOL_CONVERSION setting into the corresponding -Wbool-conversion option.
Some of the other environment variables indicate which file you should operate on, such as INPUT_FILE_PATH, INPUT_FILE_NAME, etc.
You need to tell Xcode what file(s) your rule outputs. These can be based on the input environment variables/settings, such as $(OBJECT_FILE_DIR)-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).o.
In general, this is just not something that Xcode makes easy.
Someone wrote a plugin that will allow you to use gcc from Xcode.
http://hamelot.io/programming/add-gcc-compiler-to-xcode-6/
If you have a custom gcc then you would need to change the paths around etc but the plugin should work.
I'm writing a CPython extension using Jetbrain's CLion IDE and I was hoping to get code-completion working for functions and variables inside of Python.h.
I looked through the preferences and I can't find anything relevant. How do I add code completion and inspection for included libraries?
CLion uses the CMakeLists.txt in your project to control the lookup paths for code completion and other features -- because your library includes are build specific, it makes sense in a way to put this here.
To the specific question of how to get the Python.h library signatures into autocomplete, your CMakeList file should have something like the following:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -I/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/include/python3.4m")
Where -I/path/to/file.h is the local path to the directory that contains the header files that you want to include in your build (and by proxy, your autocomplete lookup for the project).
I am using VS2010 Express and just installed Boost v1_47. I have added the 'include' folder to 'additional include folders' option, and also the 'lib' folder to the 'additional libraries' option in VS.
Then, I included boost/regex.hpp in one of my files, but actually wrote no code using boost yet. However, when building the solution I get lots of error messages, coming in two flavours:
Redefiniton errors, such as:
1>D:\boost\boost_1_47\boost/detail/interlocked.hpp(83): error C2373: '_InterlockedCompareExchangePointer' : redefinition; different type modifiers
1> C:\Program Files\Microsoft SDKs\Windows\v7.1\include\winnt.h(2597) : see declaration of '_InterlockedCompareExchangePointer'
Invalid calling convention errors (lots of these), such as:
D:\boost\boost_1_47\boost/regex/v4/regex_traits_defaults.hpp(271): error C3641: 'boost::re_detail::global_lower' : invalid calling convention '__cdecl ' for function compiled with /clr:pure or /clr:safe
Note: I haven't explicitly included winnt.h in any of my source/header files, and have tried de-activating pre-compiled headers and removing the stdafx.h includes, but it didn't solve the problem.
What's going on?
Thanks in advance
You have to make sure that you compile your program with the same settings as boost.
It seems like you used the wrong project template (CLR something) to create your application project.
You could try to modify the properties of your existing project to make it compatible with boost, but the CLR ... projects have lots of incompatible property values set by default, so i think the easiest way would be to create a new project from scratch (and import your existing code).
You should use the "Empty Project" template and create a new project, and then add your existing source and header files to it, and add the boost include path again, and add any required boost .lib files to Project Properties > Linker > Input > Additional Dependencies (Most boost libraries work out of the box without adding anything to linker inputs because they are header only, so you might not need to add any .libs).
Boost is a C++ required, designed to be consumed by C++ code, not C++/CLI code, thus it can only be used with native C++ classes, and most boost headers will produce headers when included in a source file which contains C++/CLI code.
I'm trying to use a static library created by me in Visual C++ 2005 (unmanaged C++). I declare one function "int myF(int a);" into a .h file, I implement it in a .cpp file, I compile it - the .lib file is produced.
I create a new project (a separate solution) in VC++ 2005 (also native C++), I add the paths for the include file and the lib file; when I invoke the function myF the linker reports an error: "error LNK2019: unresolved external symbol _myF referenced in function _main". if I create the client project in the same solution as the library project and then add a reference to the library projects, it works, but I'm not going to implement everything like this, but rather to add external libraries to my projects...
What is wrong?
Thank you.
You need to also include the actual .lib file in your 2nd project (not just the path to it).
There should be an option in the linker settings to do this.
It is not sufficient to list the folder in which MyStatic.lib can be found. You have to explicitly tell the linker that Dependant.vcproj is using MyStatic.lib.
In VS2005 you do this by project properties->Linker->Input->Additional Dependencies. You can also sprinkle some preprosessor stuff in the .h file to tell the compiler to tell the linker to use MyStatic.lib.
Edit:
The preprocessor magic goes like this
#pragma comment(lib, "MyStatic.lib")
(EDIT: This was a response to the question of getting the /NODEFAULTLIB error in link phase which has now been deleted... shrug)
You are mixing compiler settings if your are getting the defaultlib error. For example, if you build your library in debug and the build your main in release, you will get this error since they are built to use different versions of the CRTL. This can also happen if you use different settings for linking with the C Runtime as a object library or as a DLL. (See the C/C++ options, the "Code Generation" section, under the "Runtime Library" setting)
In many projects there isn't much you can do if you can't correct the settings of the library (for example, 3rd party libraries). In those cases you have to use the /NODEFAULTLIB switch which is a linker option in the "Input" section called "Ignore Specific Library".
But since you are in control of both the main and the library, build a debug and a release version of your LIB file or make sure your "C/C++;Code Generation;Runtime Library" settings match in both projects.
Try setting additional dependencies in the linker input for a project properties.