My builds for device keep failing, for simulator all is fine. I should note: in the past I could build for device just fine, but not anymore.
I've created a library that is the base for my project. As part of the library build process, the x86 and ARM code get merged into 1 binary, then the binary and the appropriate headers are copied to the directory ~/devel/bin
My other project has this directory included (no copy, a link). The library is added to the target of the project and the headers are included by setting the appropriate user header search path (a subdirectory of ~/devel/bin).
When I build for device I get the following warnings:
/Users/user/Desktop/ProjectName/ProjectName/ViewController.m:57: error: 'service' undeclared (first use in this function)
Service is pointer to an SDService instance (an object from the library).
Can anyone give me some pointers on how to fix this issue? I tried recreating the project, but without success.
This is seriously f*cked up. Been trying to fix this issue for the last 3 or 4 hours, but finally found the solution. The issue seems to be the compiler. I switched from LLVM+GCC to LLVM 2.0. Hope everything else works fine with this compiler, but at least I can build again.
Related
I do have a strange behavior with a flutter package I am building. It uses FFI to integrate a custom-made c++ library.
When I run flutter run -d windows --release the code starts and I do have the window with the code running.
However, when I go to the directory where the executable is stored and I run it, the program starts but the library is not loaded. I do see also that when I run flutter test, it complains that it cannot load the library. I have checked that the dll's needed are there using dependenciesGUI.exe and it seems that everything is fine, at least on my side. I do see however that within kernel32.dll I am missing ext-ms-win-oobe-query-l1-1-0.dll.
I am using Visual Studio 2022 with the x64 configuration.
Any idea on what could be the issue? For me it is VERY puzzling to be able to run the software through flutter but not with the executable directly.
Thanks!
Yours,
Pi-r
EDIT:
I compared my package with a fresh package built with flutter. With a fresh package, the behavior is the one expected: I can have the program run normally or with flutter run.
I compared the libraries of the clean package with the ones linked in my package. They are the same (with the same missing dlls which do not seem to pose an issue).
I also checked that the exported functions I needed where present -> It is the case.
The only difference I can see is that using flutter run adds a series of libraries to the path. Has I am a Linux person, I do not know of a tool that could be used to detect what is the missing library. I am open to write a separated c++ code that would load the library if it could help me identify what is the issue... ANY tips/tricks would be greatly appreciated :)
I finally found the issue I had and it is related to a different behavior under Linux and under Windows (as you will guess, I am a Linux person).
When compiled under Linux, I can force the compiler to link multiple libraries relatively to my main library. I discovered that this is not the case under Windows. Either the dlls are in the executable folder or in the Path.
For the sake of code clarity, my package uses two different libraries. Library A, which is compiled from flutter with the ffi package, called library B. First the second library was in the asset folder and with the relative linking of Linux, it was working perfectly. But it did not work under Windows until I explicitly copied the two in the same directory of the executable.
The solution was then to ensure that both libraries are copied correctly in the directory of the flutter executable. This can be done easily if you add the dependent libraries to the bundle variable in the CMakeLists.txt of the package.
However, this doesn't work when you do the testing (flutter test). As the bundle mechanism seems to be not propagated to the test function. Therefore here, the only solution is to copy the dependent libraries to the root directory of the source code :vomiting_face:
I must point out that this is only the case under Windows, for Linux, it works out of the box...
I am working on a project that uses Adobe's DNG SDK 1.6 library, and it is supposed to work on Windows and MacOS.
The library has instructions on how to build it for both platforms, but I had to figure out an error that came up on Windows with Visual Studio. I am not very experienced with big C++ projects so it was not trivial but I got it working. Most of my own code will be done in C# .Net Core, calling the native libraries using a wrapper class with P/Invoke.
Now for Mac that's a different story, I have a MacOS 11 VM, installed Xcode 12.5.1 and followed the steps provided, as expected, it does not work. Bare in mind this is my first time touching Xcode and MacOS.
The project I am trying to build is dng_validate, and it depends on two libraries built by these projects: XMPFiles64 and XMPCore64.
The library projects build without any hiccups, each one of them creating a ".a" file in the folder: dng_sdk_1_6/xmp/toolkit/public/libraries/macintosh/intel_64_libcpp/Debug, they are named libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a respectively.
When I try to build the dng_validate project, I get the following error:
Library not found for -lXMPFilesStaticDebug
Because of the the error starting with an "l" instead of "lib", under both libraries project settings, I changed the "Executable Prefix" setting to "l" instead of "lib". Rebuilt both of them and made sure the file names changed as expected. But the error persists when trying to build the main project.
Under dng_validate's project settings, there is a setting called "Library Search Paths" and it does point to the proper aforementioned folder using a relative path. I even changed it to an absolute path to see if that would make it work.
I am really lost here, does anyone have an idea of what might be causing it?
Well... After asking on other forums and almost hiring a freelancer to fix this for me, I tried another shot in the dark of renaming the library files and it worked.
I changed the extensions of libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a from ".a" to ".dylib" and it just compiled and blew my mind with it.
Recently I ran into a CMake problem that can be found in this thread:
Cmake on OSX Yosemite 10.10.3 - GLEW: package 'gl' not found
Eventually it got solved, maybe partly due to my inexperience in XCode and CMake. (I mainly used visual studio to compile projects in the past.)
After the alteration in the linked thread I got warning about my GLEW libs in CMake
(Is this something I should be worried about or is it not important?):
MACOSX_RPATH is not specified for the following targets:
GLEW_MX_shared
GLEW_shared
I simply ignored it and tried to compile my project in XCode with the ALL_BUILD target selected. In the sparky target it said the include files in main could not be found so I added the .h files into the inc folder of my project.
When I compiled again the compiler started complaining again
(I don't know what this error means and how I can fix it.):
ld: library not found for -llib
Googled it for the entire day now and I can't find anything to solve this issue.
It's so frustrating working with XCode as an IDE but I really want to learn more about different platforms and their most popular IDE's so I can make multi platform applications from the start instead of porting it afterwards.
And if it matters I am using OSX Yosemite 10.10.3.
To make my issue easier to understand, I've put a zip of my project on my dropbox.
https://www.dropbox.com/s/xnrh90kuih9ia5a/SPARKY%202.zip?dl=0
Feel free to ask questions if I explained things to briefly and again, thanks to everyone who contributes here. I really learned allot after discovering these forums.
EDIT: Alright I booted up my windows machine, generated a visual studio environment and tried to build it on there. Seems that the same problem also happens here. I looked at the linker attributes/flags and saw a lib.lib file added to the linking process which doesn't look right at all.
When removing the file, the error disappeared and many others arrived! (Which are simply solved by linking the appropriate libs so I wont handle those here.)
I misunderstood the error on my mac and thought it was referring to a random library which I needed to hunt down but actually it's a inconsistency in one of my CMake files.
EDIT2: Now I only have to find out where the lib.lib comes from and how I can ditch the flags from the project so I can generate my environment and build right away!
So moral of the story. Sometimes the solution is right in front of you and still ends up more like looking for a needle in a haystack.
I removed the following from my root CMakeLists.txt file and the random lib.lib library was gone from my generated projects
SET( PROJ_LIBRARIES "lib" )
I thought this added a folder containing libraries but actually what it did was adding another flag for a specific library because this variable was being fed to:
TARGET_LINK_LIBRARIES( ${PROJ_NAME} ${PROJ_LIBRARIES} ${OPENGL_LIBRARIES} ${GLEW_LIBRARIES} )
Has anyone run into this issue? I was experimenting with porting an existing obj-c app to Swift, and after quite a few successful builds the project will no longer build and immediately gives the error: Unable to run command 'CompileSwift normal' - this target might include its own product. Along with many other 'target might include it's own product errors'.
What I've Tried:
Checking Target Dependencies: There is nothing listed as a target dependency in Build Phases.
I've tried completely deleting the product folders, and have went through all the files multiple times but with no luck.
If I simply replace the Swift files with the old obj-c files it builds fine, no errors at all.
Restoring to a snapshot prior to any Swift modifications results in building as normal, but even if I add a brand new Swift boilerplate file and bridging header, then click build, it fails with the same errors.
I had the same issue. I couldn't work out exactly what was causing it, but realised the same code would build find on a different Xcode 6 install on a different machine.
I solved it by deleting my cached builds, etc, in ~/Library/Developer/Xcode, while Xcode is not running. "Clean" alone from within Xcode didn't do it.
You should find that when you re-launch Xcode your app will build fine.
Deleting my app target from "Build Phases -> Copy Bundle Resources" worked for me. (Somehow it was being included for bundling?)
I could reproduce the problem. In the objc-to-swift bridge header I imported a header of an objc class, which also imports swift-to-objc header. There was a cycle of imports and this could be the reason Xcode complaint.
I think for now it is best to avoid such cyclic importing between swift and objc. You might want to check that out.
While trying to get the template Xcode 4 ogre project to work, the build fails because it can't find OgreCamera.h.
I've installed Ogre to /opt/local/lib/OGRE, and specified that as the Ogre SDK location when creating the Xcode 4 project.
Needless to say, the header and framework include paths in the project settings point exactly to where all the header files are, yet not one of them can be found. I've tried commenting out the include of OgreCamera.h, and upon trying to run, the next include, OgreEntity.h, cannot be found. Commenting that out and running again, the next include can't be found, and so on (these includes are in OgreFramework.h.
I don't understand why these headers, which clearly exist when I go look for them in the Finder or Terminal, can't be found by the project, even when I specify their full path like this:
#include </opt/local/lib/OGRE/lib/release/Ogre.framework/Versions/1.7.4/Headers/OgreCamera.h>
Did I somehow install the Ogre SDK incorrectly? (I copied it from the DMG into place…)
I had the same problem, and found partial success by following rjstelling's answer from this thread:
why can't Xcode find this header file?
That solved the OgreCamera.h include issues, but now I'm stuck on including the boost libraries. They are not picked up on the search paths, or in the Indexing group as suggested in the thread above.
Basically it looks like a bug in XCode4 that has to be worked around until a patch is released. There is also more information here:
Compile, Build or Archive problems with Xcode 4 (and dependencies)