I am developing application for .Epub extension file reader.I have source code available.
But while compiling the code i am getting below error :
#error The deprecated ucontext routines require _XOPEN_SOURCE to be defined
I have gone through the internet for different kind of help, but not able to find exact solution.
Can anybody having any idea which kind of error it is?
How to resolve the above error in Xcode ?
please help out with any resolution for it.
Thanks.
You need to add a pre-processor define to your build command line (-D_XOPEN_SOURCE=600 for instance). Do this through your IDE's project properties, or by editing your makefile/changing your compiler flag environment variables.
Alternatively, add:
#define _XOPEN_SOURCE 600
before anything includes standard headers in your code.
Afterwards MAC os 10.6, you need to include "sys/ucontext.h" instead of just "ucontext.h" then you'll not need pre-processor include for _XOPEN_SOURCE.
Related
I am playing around with a project for a STM32 µC. I use the SW4STM32 workbench and CubeMX on a Mac OSX system. My project itself is fine, everything compiles accordingly and behaves on the device as expected.
For a further learning purpose, I would like to implement unit tests using the CppuUTest framework. I have set up everything, got my test directories and a makefile to configure the MakefileWorker variables in place.
However, when executing the Makefile, I keep getting the error:
error:
register 'sp' unsuitable for global register variables on this target
This error originates from the file syscalls.c (which is a file generated by CubeMX). The line causing the error is:
register char * stack_ptr asm("sp");
After doing my research, it seems like there is no easy workaround to solve the issue. The source code is generated by Cube and works fine when compiling with the sw4stm32 toolchain (which is using a mcu gcc compiler).
However, the CppUTest toolchain is using clang, which cannot cope with global register variables (as the error says aswell).
My question here ist:
Has anyone of you had the same error yet or more experience in setting up CppUTest for a sw4stm32 project on an OSx system? Does anyone have an idea how to solve this problem?
If you need more information / code snippets from me, I will gladly share it.
Thank you very much guys! Any help would be highly appreciated :-)
Cheers,
Tobi
EDIT: Getting negatives for such a detailed and HONEST question? Sometimes I don't really get Stack Overflow. Really.
Hi, I'm trying to create a PoC using Swift 5 (Xcode 10.2.1) and a modern rendition of ncurses (in this case, MacPorts' one, some 6.1.2018XXXX version)
My Poc has no code as of now, as my problems start before being able to add any sensible line to my .swift files.
So far I've done the following things:
1.- I have a proper working MacPorts ncurses library installed: that means "sudo port install htop" can build "htop" application without any problem, proving that way that my ncurses library is correctly installed (.h files seem to be deployed inside /opt/local/include/ directory)
2.- I create an empty CONSOLE APPLICATION swift program (using Xcode 10.2.1 own wizard). It just takes 4 mouse clicks, and you get some "Hello world" silly main.swift file.
3.- I create a bridging header to import my .h files (in this case ncurses.h).
The contents of this bridging header will/should be something like this:
#import "/opt/local/include/ncurses.h"
4.- I compile and run the silly empty "hello world" swift program, and I get tons of somewhat "expected" errors. Something like:
"Darwin/SDK curses.h symbol xxxxxxxxx is also defined inside your /opt/local/ncurses.h file. Bailing out." (it's not the literal error I get, you just get the idea)
So my question is:
Can I disable/remove Darwin/internal/MacOs SDK curses.h from my XCode project definition somewhere, in order my bridging header only sees one copy of my 2 (n)curses.h file (that should be my macports one)?
I've tried many things described in this other thread, but with no luck: How to disable "curses.h" header (a part of "stdio.h in Xcode 6.3 OSX Yosemite) to avoid conflicting function declarations
Specially "Enable Modules" option, which no matter the value you set it to, seems to do nothing.
BTW: I know when I might solve this .h headers issue, I will probably need to add some additional -lib linking option in the "build phase"(?) tab inside Xcode, but I'll try to manage myself when that moment arrives.
As of now my concern is "I wan't to remove Apple Internal Macos SDK curses support/files from my Xcode project". Is it achievable?
PS: I'm using Mojave 10.4.4 with no problem
I'm having the same issues, although trying to use ncurses via the Swift Package Manager. Despite being actively trying to find a solution I've been unsuccessful so far. Check my question just in case: Swift package manager unable to compile ncurses installed through Homebrew
This answer should give you all the information you need to get it working :) https://stackoverflow.com/a/56728436/554972
I am getting this error:
"error: unable to spawn process (Argument list too long)
** ARCHIVE FAILED **
The following build commands failed:
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(1 failure)
Exitcode =65 "
I went through this link:
Xcode export localization throws error "Argument list too long"
This article provides a good temporary solution of the problem stating to reduce the path hierarchy. But this does not seem to be an appropriate approach. Can anyone provide me with a different approach to the solution for this problem?
In my case, it was about custom configurations in .xcconfig files.
My config files were including Pods configurations like:
// Development.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (development).xcconfig"
// Production.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (production).xcconfig"
This produced the error you mentioned, when I added Firebase pods into my Podfile.
So to make this compile again I had to:
remove all inclusion (#include ...),
set them explicitly in the Project -> Info -> Configuration, as follows:
Quick tip:
If you don't want manually setting up corresponding target configurations (those with red icon), mark them as None and run pod install. This will automatically change it for you.
A few days ago I faced a similar challenge. I want to provide details and share my research with SO community.
First of all I found this thread and I followed the link in the asked question.
And yes, thats right, the answer marked in the link is correct, but the solutions to this problem did not suit me.
Problem
In my case, I had this problem when I changed the folder hierarchy in my project to be more convenient and suitable for me.
#oOEric option did not suit me, because according to the rules, the hierarchy of groups in Xcode should coincide with the hierarchy of folders in the system.
But I've already had about 1680 swift files to compiling.
The problem was that I had too long path to the compiled files and their number was too large.
Research
Then I start research and found swift jira with the same bug.
Here some links:
Main
Linked Issue 1
Linked Issue 2
Linked Issue 3
Bug on Open Radar
But here I didn't find some solutions for me.
Most of all I was pleased with this response of the swift developers.
Again, this is an Xcode-side issue, not a Swift-side issue. Commenting here won't make the Xcode engineers work any faster!
(We're not all the same people at Apple.)
Okey, after this answer, I was finally convinced that if it is an Xcode bug, then the solution should be sought in Xcode.
Solutions
Temporary solution
You need to move your project higher in the hierarchy of your system.
I choose this one, because I have really big project and the use of other solutions will require more than one day from me.
In my case, I conducted an experiment and calculated that the length of the path to the project should be no more than 50 characters.
But this is a temporary solution. If your project grows further, you will have to shorten the path or use other solutions.
Cocoa Touch Framework target
This solution is suitable for files that do not use dependencies.
First of all you need to add Cocoa Touch Framework as a target to you main project.
This target should be added automatically to Embedded Binaries and Linked Framework and Libraries.
After this you need to find some files without dependencies and change target membership to your "TestTarget".
Don't forget classes, properties, methods, enums, protocols from cocoa touch framework should have open or public access.
And don't forget clean your DerivedData folder.
Modular iOS
This solution has a more integrated approach.
If you want to use any dependencies in your Cocoa Touch Frameworks you should go to this guide and make more complex refactoring for your big project!
Link to solution
I think this is the best solution.
I hope this big answer will help someone!
I solved this by setting build system to Legacy build system
in file-> workspace setting -> select workspace setting
I solved this by reducing the hierarchy of groups in Xcode.
e.g. original files at project_name/project_name/About/Model/Text
I removed the groups "Model", "Text" and moved files under project_name/project_name/About/
I made simple script for temporary fix that problem. https://github.com/gregoryvit/flatter
It simply move all swift files in Xcode project to root group.
Error - unable to spawn process (Argument list too long)
There are many reason for this error. Some of these are mentioned below:
Your project might have many swift files (say more than 2000)
Most of the Swift source files may be deeply nested inside directories
Many of these files have absolute paths with more than 150 characters (eg. /Macintosh HD/Users/jayprakashnd/mySampleProject/Module1…)
Xcode swift complier takes the absolute paths of all source files while so compiling, the ARG_MX limit is reached and build fails.
This has been fixed in Xcode 11 wherein a flag is used to set unlimited number of swift files.
Solutions:
Switch to Xcode 11 and add USE_SWIFT_RESPONSE_FILE to YES in build settings - User Defined Section
If you cannot switch to Xcode 11 then take a new checkout of your project in Macintosh HD ▸ Users directory with folder name as minimal as possible.
Solution 2 worked for me like a charm!
It happened to me when I use Xcode 11 beta version using Live Preview. Then I solved it by restarting Xcode after that error has gone.
I have fixed this issue, moving my folder of My Xcode project to the mac root and changing my name Folder to less characters.
Terminal: cd /
Change name folder to BX (example).
xcode11
-build setting
-user-defined
-add setting: USE_SWIFT_RESPONSE_FILE
-setValue: YES
Doing this you enable xcode to have more files than is allowed. But im not sure if this always solve the problem.
I have changed build type to legacy and it also resolved problem for me, both locally and on our CI builder. For me it was caused during checking Podfile.lock and Manifest.lock. Probably this could be skipped in our pipeline since we are always installing pods on CI.
If you faced this issue on your Flutter project while building in Release mode (or Archive) check out my this answer: https://stackoverflow.com/a/61446892/5502121
Long story short:
set your build system to New Build System in File > Project Settings…
remove ios and build_ios folders
run flutter create . to init new ios module
run pod install
run flutter pub get
check your Xcode build config (it should be Release mode and General iOS Device)
and you're good to go
I have the same problem. I fix it using a temporary solution, however that work for me.
My solution is to change the Derived Data folder to a directory with a shorter path.
The Steps is as the following:
Xcode -> File -> Workspace Settings... -> Select Custom Location for Derived Data and give a shorter path as the location.
I am trying to build lite version of my iPhone application using AdMob. I followed the guidelines here http://www.iphonedevsdk.com/forum/iphone-sdk-development/11358-creating-lite-version-app.html and created two different targets. In the lite version I added a macro called LITEVERSION which I am checking using #ifdef and doing the appropriate things.
But when I build the lite version of the app, I get a linker error
ld: library not found for -lAdMobDevice
collect2: ld returned 1 exit status
However I am able to build the full version without any issues and also noticed that build is working fine (for the fullversion) even if I remove the #ifdef macros. This suggests that the libAdMobSimulator.a library is linking properly for the full version however it fails on the lite version.
Any pointers would be greatly appreciated!
Cheers
Jugs
When I had this problem, the cause was that I'd added the library into Xcode by dragging it in like a regular source file.
The fix was to remove it, and then add it properly using the "Add->Existing Frameworks..." dialogue.
I got similar error as I was using CocoaPods libraries
library not found for -lPods-MyApp
I got the error because I opened xcode project instead of workspace.
I was using CocoaPods, and ran pod install, and that fixed it.
I figured out what he problem was. I just removed all frameworks and libraries and added them back in for both the targets and it worked!
Cheers
I cause this because of a libray libMobClickLibrary.a which is used in youmeng sdk missed. I fix the issued after copy libMobClickLibrary.a to the project floder.
I had the same problem with Google Analytics library. My problem was that I forgot to add the path to the Library Search Paths in my target's build settings. (Target -> Build Settings -> Library Search Paths)
Just upgraded to Snow Leopard, installed Xcode 3.2, then installed iPhone SDK 3 for SL.
In a project, I now get the following error on build:
ld: library not found for -lcrt1.10.6.o
I've searched around the net, but nothing helpful can be found.
Edit Project Settings -> In the build tab -> For Mac OS X Deployment Target, change it to 10.5 for XCode 3 (not 10.6 even if on 10.6) and see if that helps.
For XCode 4, you'll need to set it to 10.6
P.S. Make sure you set that for all targets, not just release or debug. (if you didn't, one would fail, the other wouldn't)
Add the following to ~/.profile (for Mac OS X 10.5):
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
I was able to fix this problem by adding the following to my Makefile:
CFLAGS="$(OTHER_CFLAGS) -mmacosx-version-min=10.5"
LDFLAGS="$(OTHER_LDFLAGS) -mmacosx-version-min=10.5"
Ostensibly, this is only required when building outside of Xcode. This problem frustrated me long enough that I figured it would be useful to share my experience here.
It looks like you're picking up libraries from /usr/lib, which is wholly inappropriate for the iPhone SDK. I would assume you've changed your build settings to add /usr/lib to the library search paths. This should be completely unnecessary in the first place, as /usr/lib is in the compiler's standard search paths, but if you need to have a modified search path like this, make sure to use $(SDKROOT)/usr/lib instead.
Setting deployment target to compiler defaults solved the problem. Don't change anything else.
The compiler normally uses crt1.o combined with crt[i/n].o and crt[begin/end].o to support the constructors and destructors (functions called before and after main and exit).
This error could be caused by this missing library file for the specific deployment target.
First, do some investigation, like:
List all your deployment targets:
ls -la /Developer/SDKs
Find which crt1 libraries do you have for which environment
find /Developer/SDKs -name crt1\*
You could see something like:
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
As you can see in above example, crt1.10.6.o is missing for MacOSX10.5.
Solution 1
You can solve that by creating the link to the missing file pointed to the other environment, or you could change your deployment target.
E.g.
ln -s /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o /Developer/SDKs/MacOSX10.5.sdk/usr/lib/
Other reason why it's missing, is that you could have different gcc installed in your system. E.g.:
which gcc
xcrun -find gcc
brew list | grep gcc; brew list gcc47
Solution 2
So when you're compiling using make, you can actually specify the right compiler by CC variable. E.g.
CC=/path/to/gcc-3.4 make
Solution 3
What you can also try is specifying the right target deployment environment variable for gcc, e.g.:
export MACOSX_DEPLOYMENT_TARGET=10.5
If this works, then you can add this library path to your shell profile (~/.profile).
E.g.
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Or by temporary exporting them.
How to test
Create the example conftest.c file with the following code:
#ifdef __GNUC__
yes;
#endif
And try to compile it via:
gcc conftest.c
cc conftest.c
cc conftest.cc conftest.c
Wasted few hours on this one...
Interestingly, for me the problem was only for Simulator-Debug.
It wasnt complaining for Simulator-Release or Device Debug/Release!
anyway, Changing Deployment Target to 10.5 solved this for me!!
This problem solved by setting Mac OS X Deployment Target to 10.5 and after this set back to Compiler Default :)
I had this problem when I was using Xcode 4 on one machine and Xcode 3.2.6 on another. The two versions are supposed to be able to swap .xcodeproj files between them but I found that in the project.pbxproj file (inside the .xcodeproj directory), there were still a couple of places that read:
MACOSX_DEPLOYMENT_TARGET = 10.6;
I quit Xcode and went and changed the three occurrences to:
MACOSX_DEPLOYMENT_TARGET = 10.5;
After reopening the project, I could build again. Whew!
I had the same error message, none of the above solutions worked for me. I resolved it by deleting the *.pbxuser and *.mode1v3 files inside the xcodeproj file.
Control/click the xcode *.xcodeproj file
Select the "show package contents" option from the menu
A window will open with the contents
Delete the pbxuser/mode1v3 files that start with your user name
Rebuild the project
I had the same issue in a Fortran Makefile.
Added the following option after the compiler (For OSX 10.5):
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
e.g.,
g77 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Now the compiler will find the library you want !
Add the following to ~/.profile (for Mac OS X 10.5):
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Given Kirandan's limited scenario (Snow Leopard, Xcode 3.2.1, iphone, library path error), Stefan's answer (above) worked for me, except my exception was with 10.5 (-lcrt1.10.5.o).
Elsewhere, I'd seen an answer by Gabor Cselle (author of reMail), and he fixed this specific issue by using a symbolic link (someone referenced this page, by the way), but he noted this was not the best way.