I've created a simple project to get myself accustomed to meson, but the build keeps failing.
This is what I did (to set up the environment, and to build):
set CC=clang
set CC_LD=lld
set CFLAGS="--target x86_64-pc-windows-msvc"
meson build
cd build
ninja
My meson.build is as follows:
project('EtaClient', 'c')
src = ['src/main.c', 'src/linkedlist.c']
executable('EtaClient', src)
target = 'x86_64-pc-windows-msvc'
While building, I get the following errors (the obj files are built successfully, but they're not linked and thus the exe isn't built):
LINK : warning LNK4044: unrecognized option '/-subsystem'; ignored
LINK : fatal error LNK1181: cannot open input file 'console.obj'
clang: error: linker command failed with exit code 1181 (use -v to see invocation)
When I look in my build.ninja to see what's going on, I find:
build EtaClient.exe | EtaClient.pdb: c_LINKER EtaClient.exe.p/src_main.c.obj EtaClient.exe.p/src_linkedlist.c.obj
LINK_ARGS = "-Wl,/nologo" "-Wl,/release" "-Wl,/nologo" "-Wl,/DEBUG" "-Wl,/PDB:EtaClient.pdb" "-Wl,--subsystem,console" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32"
I replace "-Wl,--subsystem,console" with "-Wl,/subsystem:console", and the build compiles successfully, but I have to manually make this edit each time I modify my meson.build.
Could someone tell me why this happens, and how to set up meson to generate the correct flag?
Thanks in advance.
use clang-cl instead of clang and leave out the defintion of the linker when you are on windows
set CC=clang-cl
set CFLAGS="--target x86_64-pc-windows-msvc"
meson build
cd build
ninja
see
https://github.com/mesonbuild/meson/issues/4232
I am implementing BugSense using link http://docs.splunk.com/Documentation/MintIOSSDK/latest/DevGuide/Configureyourprojectforsymbolication
I have added the script for Configure server-side symbolication
SCRIPT=/usr/bin/find "${SRCROOT}" -name splunkmint_postbuild_dsym_upload_script.sh | head -n 1
/bin/sh "${SCRIPT}" "API_KEY" "API_TOKEN"
but when i am compiling my project xcode gives
/bin/sh: : No such file or directory
I got the solution.
I did't add SplunkMint.framework properly its was only referenced but not present in bundle.After adding referenced SplunkMint.framework in bundle I set the flag "-ObjC" and "-all_load" in other linker flag(In build setting) then compile.
Now its working fine.
Recently I am doing some AllJoyn development on iOS and OS X. When I run xcodebuild for alljoyn_darwin.xcodeproj using command line as below:
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -project alljoyn_darwin.xcodeproj -scheme alljoyn_core_ios -sdk iphoneos -configuration Debug PLATFORM_NAME=iphoneos
I got an error like this:
export variant=normal
/opt/local/bin/scons -u OS=darwin CPU=arm BR=on BINDINGS=cpp SERVICES= WS=off VARIANT=Debug --
scons: *** No SConstruct file found.
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.4/SCons/Script/Main.py", line 920, in _main
Command /opt/local/bin/scons failed with exit code 2
** BUILD FAILED **
The following build commands failed:
ExternalBuildToolExecution alljoyn_core_ios
(1 failure)
I really have no idea why I got this, I followed all the instruction in the official site--Build From Source and I am sure I set the correct OPENSSL_ROOT path. I installed scons using Macport and it was installed correctly. I tried double-click the alljoyn_darwin.xcodeproj from finder but I got the same error.
scons: *** No SConstruct file found.
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.4/SCons/Script/Main.py", line 920, in _main
Command /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/scons-2.3.4 failed with exit code 2
So I am stuck here. But the thing is I can successfully run AllChatz sample in sdk_14.12 for iOS in iphonesimulator for iPhone6. openssl version is 1.0.2 and I tried build both for alljoyn sdks 14.06 and 14.12. same error happened. I don't know if this is related. Anyone can help here? Many thanks.
The problem is that scons cant find the root-level SConstruct script, which probably doesnt help much as you can see that in the error :)
When you use the "-u", that tells scons to look up the directory structure for the root-level SConstruct script.
SCons must be executed from within the project directory structure. Look for the root-level SConstruct, and make sure you're executing scons from within the project directory structure.
I am working on a project that was previously done and uploaded on app store.When I run this app in Xcode 5.0 it is working fine but when I run this on Xcode Version 5.1.1 (5B1008) I am getting Linker error on both device and simulator.
Error Message- Library not found for -llib. (clang: error: linker command failed with exit code 1 (use -v to see invocation)).
I have searched a lot but I didn't get any thread about Library not found for -llib error. Is there anything I have to change in build settings to resolve this?
Look at the linker command line in detail for the -L options being used:
Then use Terminal or Finder to see if your libXXX.a file exists in those directories. If the library exists elsewhere then you need to configure your Library Search Paths:
However there several details which you have not provided in your question when using a library within an app:
Is the library built as part of the Xcode project/workspace (as in the first image)?
Is the library supplied by a third-party with binary (.a) and header files (as in the second image)?
TL;DR: I ran make in the wrong directory so the paths were messed up.
Problem:
>make
linking ../build/release/yubikey-personalization-gui
/usr/x86_64-suse-linux/bin/ld: cannot find -llib
...
I ran into this when compiling the Yubikey Personalisation Tool. I tracked down the -llib call in my Makefile which looked like this:
...
LINK = #echo linking $# && g++
...
LIBS = $(SUBLIBS) -L/usr/lib64 -L../lib/release -llib -lyubikey -lykpers-1 -lQtGui -L/usr/lib64 -L/usr/X11R6/lib -lQtCore -lpthread
...
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)
So it was setting a variable called LINK which would print "linking" and then call g++, which is the compiler.
Then it set the var LIBS which would hold the ominous -llib.
Then it composes and runs the command $(LINK) ... $(LIBS).
Which runs g++ with the parameter -llib.
And what does that do? Turns out -l<something> is telling the compiler to use the something-library. So it asks for the library called lib here. Which is strangely generic. I figured out that the sources came with a directory called lib/, which was at ../lib.
So starting make from a directory higher up fixed it.
You should remove libstdc++ from other linker flags in your xcode project
https://stackoverflow.com/a/53103383/1344237
I am trying to compile Sofia-SIP library for iOS for architectures armv6 and armv7 but I am running into problems. Below is what I am doing.
export DEVROOT=/Applications/Xcode_4_6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS6.1.sdk
export CC=$SDKROOT/usr/bin/llvm-gcc-4.2
export CFLAGS="-pipe -no-cpp-precomp -isysroot $SDKROOT -arch armv7"
export LDFLAGS="-syslibroot $SDKROOT -arch armv7"
export CPP=$SDKROOT/usr/bin/llvm-g++-4.2./configure --host=arm-apple-darwin10
sudo ./configure --host=arm-apple-darwin10
RESULT
Password:
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... x86_64-apple-darwin12.5.0
checking host system type... arm-apple-darwin10
checking target system type... arm-apple-darwin10
checking cached information... ok
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-apple-darwin10-strip... no
checking for strip... strip
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for arm-apple-darwin10-gcc... no
checking for gcc... gcc
checking for arm-apple-darwin10-gcc... gcc
checking whether the C compiler works... yes
PROBLEM
I want the script to use llvm-gcc compiler. But instead it is looking for arm-apple-darwin10-gcc which it could not find and then finally ends up using gcc compiler.
I fought with this for a weekend, won the battle (with a lot of help), and have the following to return to the community:
Regarding su_os_nw.c and the
SCDynamicStore: function has been explicitly marked unavailable for iOS
issue:
I was about to give up, but noticed that a fellow named Antonis Tsakirids from Restcomm reported success in integrating Sofia in their iOS SDK.
I then went to their git repository and had a look at their SDK.
In /dependencies/sofia-sip/libsofia-sip-ua/su/ I found the culprit: su_os_nw.c
They elegantly updated
#if defined (__APPLE_CC__)
to
#if defined (__APPLE_CC__) && !defined(TARGET_OS_IPHONE)
This solves it…
…but it does not solve it just by itself…because apparently since Xcode 7, Apple did some toolchain utilities shuffling.
Stuff is not located in “usual” locations anylonger, and MishaBruckman’s $DEVROOT got obsolete.
For instance , I got errors about “ar” not being found.
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer”
maps to /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
However, the toolchain utilities (ld, ar, as, nm, ranlib, along with the almighty clang) have been moved to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin.
I bolded the part that should map to the new $DEVROOT.
Hope this helps someone save 2 weekend days of their life...
…and in the end, the 2 points expressed above were not enough to get out of the woods…Compilation did finish OK and I left it at that initially.
However, today I wanted to actually use the library. Created a new project, imported the library, hit Build and…more suffering…
libsofia-sip-ua.a does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target for architecture armv7.
At first I went “say wha’…?”
what’s this mumbo_jumbo about setting stuff in Xcode? I did things the old_school way, compiling in command line…
what do you mean “obtain an updated library from the vendor”…the “vendor” is me, I’m building the library…
what is this strange bitcode thing, anyway?
After doing my homework regarding bitcode I started wondering what hides behind Xcode’s ENABLE_BITCODE… Turns out it “means” passing the “-fembed-bitcode” flag to clang.
In conclusion, the line
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
became
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -fembed-bitcode -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
Rebuilt Sofia with the new settings, but then it started complaining that even though the main project itself is going ok, it's SUB-LIBRARIES (for example libstun.a) are not compiled with bitcode. A "make clean" got rid of the old garbage and compilation finished ok. Imported the newly produced lib into my Xcode project and everything was ok as well.
And that finally concludes it. Build successful for a project under Xcode 7 / iOS9 integrating Sofia library, in anno domini 2015…
...aaaand...I was still not out of the woods...
As soon I decided to add arm64 architecture to my project, Xcode started again to complain about Sofia:
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (arm64)
Undefined symbols for architecture arm64
Pretty simple, I thought: I'll just replace armv7 with arm64:
export ARM_ARCH="arm64”
After that modification, disaster struck while ./configure-ing:
checking for gcc... /usr/bin/clang
checking for gcc... (cached) /usr/bin/clang
checking whether the C compiler works... no
configure: error: in `/work/fromSourceforge/sofia-sip-1.12.11':
configure: error: C compiler cannot create executables
See `config.log' for more details
The next day was spent figuring out what was wrong (I could not ./configure anylonger, even reverting back to armv7)
stormed stack overflow; no solution helped
checked ad re-checked every path on the system...I was surprised to find out that one can find clang and gcc in 3-4 places throughout macosx, but I digress...
trying to reinstall Xcode Developer Tools
ended up reinstalling Xcode itself...
...nothing helped.
An eagle-eyed colleague spotted what was wrong:
export ARM_ARCH="arm64”
The last quote sign was not "the same" as the first quote sign. The first quote sign is "the correct kind of quote sign".
Even if I didn't touch the second one with my own hand, TextEdit changed it all by itself while I was converting v7 to 64. Apparently it's "a feature", called SmartQuotes. I could not disable it, by the way.
Mental note: NEVER EVER use TextEdit again to edit the .bash_profile file.
Finally, I found myself in the posession of the 64 bit version of Sofia. Plugged it into my Xcode project, aaaaaaand....
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (armv7)
Undefined symbols for architecture armv7
Hmmm...if I build it for 32 bits, it complains about 64 missing...If I build it for 64 bits, it complains about 32 missing...
Turns out there's a way to fuse together multiple libraries into a single "fat" one.
The utility is called lipo and you use it something like this:
lipo -create "path_to_lib_1" "path_to_lib2" -output "path_to_desired_name_of_the_merged_library"
So: SIP-ing along with Sofia, under iOS, as a single library that does both 32 and 64 bits...
Heewhhh...
.....aaaaaaaaand we're still not done...!
Problem: trying to do anything (REGISTER, for instance) promptly resulted in a 503 DNS Error
Cause : Sofia searches for the name servers list in etc/resolv.conf
Obviously, this being iOS, it either does not exist, OR it's outside of the app sandbox.
Solution : it's the second time when this guy, Antonis Tsakiridis, saves my ass. Respectful bow.
First, he talks about what he intends to do.
Second, he shows what he has actually done.
However, the solution exposes a new...
Problem: _res_9_init - undefined symbol for architecture (armv7 or arm64 here, depending on what I happened to have set for ARM_ARCH), while recompiling Sofia
Cause : I don't know. I can only infer from the solution, that the linker needed to be told about the "resolv" library
Solution : added -lresolv in two places:
LDFLAGS (in the .bash_profile file)
in the Xcode "application" project (the one that exercises the library); Targets ---> Linking ---> OtherLinkerFlags
Just like before, although the above solves what it was trying to solve, it also advances us to the next...
Problem: conditional execution of code under #IOS_BUILD (part of AT's solution at first problem) did not take place. Still getting 503 DNS Error...
Cause : I could not figure out for the life of me WHERE IT'S ACTUALLY DEFINED. Of course, defining it anywhere in my own code could have no effect, since Sofia is supposed to be an already compiled dependency; we don't get another chance at the preprocessor crunching through her code.
Solution: I replaced the IOS_BUID #define with an environment variable called IOS_BUILD that has the value...well...IOS_BUILD. I told Xcode about it (I'm trying to use not the word "define" to avoid confusion) at
Product ---> Scheme ---> EditScheme ---> Arguments ---> EnvironmentVariables.
In Sofia, I just substituted #Ifdef IOS_BUILD with calls to getenv() and strcmp().
After all that, behold...REGISTER takes place...
Also, DNS settings are correctly detected everytime I connect the iPhone to another wi-fi, thanks to Sofia's smart "resolver".
Note that llvm-gcc is deprecated; you should be using clang instead:
% ls -l /usr/bin/llvm-gcc
lrwxr-xr-x 1 root wheel 5 Nov 8 2013 /usr/bin/llvm-gcc# -> clang
The following seems to work for me:
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer"
export SDKROOT="$(xcrun --sdk iphoneos --show-sdk-path)"
export CC="/usr/bin/clang"
export CXX="/usr/bin/clang++"
export LD="${DEVROOT}/usr/bin/ld"
export AR="${DEVROOT}/usr/bin/ar"
export AS="${DEVROOT}/usr/bin/as"
export NM="${DEVROOT}/usr/bin/nm"
export RANLIB="${DEVROOT}/usr/bin/ranlib"
export LDFLAGS="-L${SDKROOT}/usr/lib/"
export ARM_ARCH="armv7" # or "armv6" and adjust the --host=[...] flag below
export CFLAGS="-arch ${ARM_ARCH} -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
export CPPFLAGS="${CFLAGS}"
export CXXFLAGS="${CFLAGS}"
Configure:
./configure --host=armv7-apple-darwin
Build:
make
Verify:
file `find . -name \*dylib`
Output:
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib: Mach-O dynamically linked shared library arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib.dSYM/Contents/Resources/DWARF/libsofia-sip-ua.0.dylib: Mach-O dSYM companion file arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.dylib: Mach-O dynamically linked shared library arm
Credits:
most flags above were adapted from this question
xcrun command via a comment by Alex Denisov on this page
Notes:
I dropped the -miphoneos-version-min=[...] flag from the other question as I did not think it was relevant to your question; up to you if you want to add it back into CFLAGS.