Roger, it would be much easier if you actually posted your sample Xcode project. Most of the trying you're trying are either irrelevant to the project (Makevars) are not necessary or don't work
In principle the right way to go about this is to use the R framework - that's how you link Xcode projects to R (see the Mac GUI as an example or the REngine Obj-C R API). You have essentially the choice of either using the R build system or using Xcode's build system. It appears and you are trying to mix pieces from both which won't work. Cheers, Simon On Aug 17, 2014, at 11:11 PM, Roger Dean <[email protected]> wrote: > Hi again Colleagues, > Following my earlier query, I carefully followed (and extensively trialled) > the helpful leads you gave. (I had to repost this new query, as my first > sending was unsuccessful. Sorry about that.) > > In essence, you confirmed that the build failure was due to my having allowed > a conflict to develop between String.h from Rcpp and string.h from the > standard C library, so that at some points it was finding the wrong one of > these two headers. The cumulated advice on this I gleaned was to avoid > duplication of RCpp header paths offered in the search dialogue, and to use > -idirafter to try to ensure that the R-associated headers are searched after > the path containing the standard libstdc++. I did this, and got rid of the > numerous errors that previously appeared early in the linking process. But > now I still seem to have a residue of the problem appearing when the > Rinside_sample0 main function gets into operation. > > I would very much appreciate a further burst of advice on solving this > remaining problem. > > FIRST: here is the problem as shown by the error messages from Xcode: > Three 'Apple Mach-0 Linker (ld) Errors': > : "RInside::parseEvalQ(std::string const&)", referenced from: > _main in rinside_sample0.o > : "RInside::operator[](std::string const&)", referenced from: > _main in rinside_sample0.o > Symbol(s) not found for architecture x86_64 > Linker command failed with exit code 1 (use -v to see invocation) > > And the detail: > Ld > /Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppifdcdgmneurclwb/Build/Products/Debug/rRinsideXcodetest2 > normal x86_64 > cd /Users/RogerDean/Desktop/RInside-test/rRinsideXcodetest2 > export MACOSX_DEPLOYMENT_TARGET=10.9 > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ > -arch x86_64 -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk > > -L/Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppifdcdgmneurclwb/Build/Products/Debug > > -L/Users/RogerDean/Desktop/RInside-test/rRinsideXcodetest2/rRinsideXcodetest2 > -F/Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppifdcdgmneurclwb/Build/Products/Debug > -filelist > /Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppifdcdgmneurclwb/Build/Intermediates/rRinsideXcodetest2.build/Debug/rRinsideXcodetest2.build/Objects-normal/x86_64/rRinsideXcodetest2.LinkFileList > -mmacosx-version-min=10.9 -stdlib=libstdc++ -lRlapack -lR -lRblas.0 > -lRInside -Xlinker -dependency_info -Xlinker > /Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppif! d! > cdgmneurclwb/Build/Intermediates/rRinsideXcodetest2.build/Debug/rRinsideXcodetest2.build/Objects-normal/x86_64/rRinsideXcodetest2_dependency_info.dat > -o > /Users/RogerDean/Library/Developer/Xcode/DerivedData/rRinsideXcodetest2-cfwgtxcrotrppifdcdgmneurclwb/Build/Products/Debug/rRinsideXcodetest2 > > Undefined symbols for architecture x86_64: > "RInside::parseEvalQ(std::string const&)", referenced from: > _main in rinside_sample0.o > "RInside::operator[](std::string const&)", referenced from: > _main in rinside_sample0.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > so it seems still to be an issue to do with string operation as far as I can > tell. I have tried a range of the architecture options, and currently have > 'Native Architecture (x86-64)' as the choice. > > SECOND, here are the places in Xcode and details of the paths I am currently > providing (I have tried a range of alternative sites for placing these paths > and directives in the Xcode build settings, that either worsened or did not > change the outcome): > ************ > The 'system' paths: > //:configuration = Debug > HEADER_SEARCH_PATHS = /$(inherited) > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include > > //:configuration = Release > HEADER_SEARCH_PATHS = /$(inherited) > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include > > //:completeSettings = some > HEADER_SEARCH_PATHS > > the 'R' paths: > I have tried these in "User header search paths" with "Always search user > paths" = YES, with similar results. The guidance on Always search user paths > seems unclear, and also inconsistent with the idea of the -idirafter > directive, so I currently have these paths in "Other C++ Flags" as follows: > > //:configuration = Debug > OTHER_CPLUSPLUSFLAGS = > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RInside/include > > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/include > > //:configuration = Release > OTHER_CPLUSPLUSFLAGS = > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RInside/include > > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include > -idirafter/Library/Frameworks/R.framework/Versions/3.1/Resources/include > > //:completeSettings = some > OTHER_CPLUSPLUSFLAGS > > *********** > Third, there is also the direction to use the particular libstdc++ library, > and the restriction of macosx types. These I have currently placed in > OTHER_CODE_SIGN_FLAGS: > > //:configuration = Debug > OTHER_CODE_SIGN_FLAGS = -stdlib=libstdc++ -mmacosx-version-min=10.6 > > //:configuration = Release > OTHER_CODE_SIGN_FLAGS = -stdlib=libstdc++ -mmacosx-version-min=10.6 > > //:completeSettings = some > OTHER_CODE_SIGN_FLAGS > > NB Judging by the detail above, the latter part is getting over-ridden > somehow so min=10.9. > > > Finally, I'll confirm that I also have set up the .R/Makevars according to > the best advice I could again glean from your comments, the related SO posts, > and my searches, dealing particularly with selecting the clang++ compiler. > As you see above, I chose to put the -idirafter directives into the Xcode > settings rather than in Makevars, which seemed more appropriate since I think > these directives to some degree specific to this R project and not general to > all R projects. I did also try placing all the -idirafter paths in Makevars, > without any improvement, Here is my current .R/Makevars: > > CC=clang > CXX=clang++ > CFLAGS="-mtune=native -g -O2 -Wall -pedantic -Wconversion" > CXXFLAGS="-stdlib=libstdc++ -mmacosx-version-min=10.6 -mtune=native -g -O3 > -Wall -pedantic -Wconversion" > FLIBS=-lgfortran > F77="gfortran-4.2 -arch x86_64" > FC=$F77 > OBJC=clang > So I do have some duplication, but as the specs are the same I assume this > will function as a safeguard. Again, I have fiddled with most of these > permutations. > > A subsidiary question I have is whether the libR.dylib and libRInside.dylib > are actually needed in the Xcode project, or whether they will/should be > built during the compiling? > > I am hoping another round of advice from you experts might allow me to solve > my remaining problem. Many thanks again in advance for your advice and time. > > Roger Dean > > > Prof Roger Dean, MARCS Institute, University of Western Sydney > [email protected]<mailto:[email protected]> > > > > > [[alternative HTML version deleted]] > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
