I install a TURN server for my webrtc app, while configuring TURN server
source code, there are 3 options for me to choose:
--enable-debug-build : allow to compile with debug informations
default=no
--enable-fdsetsize=number : allow to preconfigure FD_SETSIZE macro
(must be a number >=32) default=no
--enable-xor-peer-address-max=number : allow to preconfigure
XOR_PEER_ADDRESS_MAX macro (must be a
number > 0) default=5
and I do not know how to use FD_SETSIZE option? Does anyone tell me?
Related
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.
Our windows builds generate hundreds of warnings of this form:
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/FORCE' specification
I would like to disable this warning, at least temporarily, to make it easier to spot and resolve other warnings.
I've seen Visual C++: How to disable specific linker warnings? which suggests that I should be able to set /ignore:4075, but am unsure which qmake variable should I add that to?
I've looked at the variables in the qmake Variable Reference, and there are plenty of LFLAGS-related options, and without a large amount of trial and error, I'm unsure which to use.
So, what qmake variable should I adjust, with what value, to turn off LNK4075?
Which of the LFLAGS you use depends on what you are building.
Windows Console (no GUI) App => QMAKE_LFLAGS_CONSOLE
Windows Console (no GUI) DLL => QMAKE_LFLAGS_CONSOLE_DLL
Windows GUI app => QMAKE_LFLAGS_WINDOWS
Windows GUI DLL => QMAKE_LFLAGS_WINDOWS_DLL
To use them, just add the flag you need to the appropriate one.
QMAKE_LFLAGS_xyzzy += /ignore:4075
If you are really in doubt, add it to all of them.
I'm trying to use differents configurations for multi-library use.
I explain : i have to use many library for one solution, but i need to change the configuration for each library target, for a debug use of my solution some library will be in 'debug' mode but some other needs a 'Render' configuration. (It's 3rdParty project i can't edit them)
I want to know if its possible.
Thanks !
Here an example the result i wanted to have :
http://i48.tinypic.com/mtugqf.png
You can almost do this. CMake allows for extra configurations by setting CMAKE_CONFIGURATION_TYPES, so in your case this would be
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES};Render" CACHE STRING "" FORCE)
This needs to be after the project command.
However, this adds a new configuration type to all targets. I don't think CMake has the ability to mix different configurations for individual targets. You'd still have to manually modify the specific libraries' configs via the Configuration Manager once CMake had created the .sln.
This post and this post says that with Visual Studio, the run time library can be static/dynamic, and it shouldn't be mixed. Even one can have debugging version/release version for the library. And there are four possibilities (static/dynamic and debug/release).
So, with Visual Studio, the library provider has to provide four different versions of the same library?
ADDED
I tried to link CppUnit test (debug) with release build library, and I got an error. So, I wondered normally library provider might need to provide all the possible combination of libraries.
depends..
under normal cicrcumstances you only provide a realease version. Then you have the option for static/dynamic. In the case of static, you don't have to provide anything since it's static: your lib already contains all functions from the crt it needs. In case of dynamic, it also depends: if you expect your clients to build applications using your lib, they already should have the required lib on their build machine. Else, yes, you can provide them with a crt installer for the dynamic release version (or just ship the corresponding dlls but that's considered rather bad practice)
Also if I remember correctly, you cannot redistribute the debug versions of VS's debug libraries, so in the end this would mean the library provider should only provide one version.
This is really the case with ANY C++ library (we have the same 4 options in our Unix side builds).
Please note that you only have to provide the debug versions if you intend them to be used by other developers, who will need them to debug - otherwise, for end users, you can only provide optimized ones.
how to solve #error : Must define a target architecture in wince mfc application?i got to know that we need to use device header and libraries but how can i use that?
Presumably, the error is because you're trying to build the application against the (desktop) Windows SDK. The easiest thing to do is to create a new "Win32 Smart Device" project and add your code to it.
Alternatively, check the "Compile for architecture" setting under project properties -> C/C++ and ensure that it is set for the appropriate architecture.
I think you need to globally define some macro like _X86_ in the project options, but I'm not sure.