Date   

Re: .xcconfig not being used for prefix header

Alex Zavatone
 

Oh, have you tried the Legacy Build System?

It is under your File menu in either Workspace Settings or Project Settings.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Re: .xcconfig not being used for prefix header

Alex Zavatone
 

Check your build settings for the location of your precompiled header.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Profiling UI Tests.

Alex Zavatone
 

I’m sure you all know that you can right click on a test in Xcode, select Profile and then run that test in Instruments.

Oddly, when I set my Test scheme to ask which test to launch or use NSZombies or Leaks, the only test that runs is Allocations, not the one I selected.

Any ideas? Are there any mutually exclusive scheme settings that would prevent this?

Thanks in advance.

Alex Zavatone


Re: .xcconfig not being used for prefix header

John Brownie
 

I found the issue in the end. For some reason, the configuration in one project was set at the project level, while it was at the target level in the other. When it is set at target level, definitions aren't applied to the precompiled header. Fixing that got me a clean compile at last.

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: .xcconfig not being used for prefix header

John Brownie
 

Header maps doesn't appear to be the issue. It is the fact that no header search paths are specified for the prefix header, except for one target. Looking at the two targets in the same project, both have the header file search path set correctly, and at the same level, but one ignores it for prefix, while the other doesn't.

Not having dealt with setting up .xcconfig files in many years (and this was already set up in the app template), I don't know how to ensure that they are invoked for any given target. Can someone point me to some useful documentation?

John

Sak Wathanasin wrote on 22/7/19 13:11:



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Can't get IBOutlet to work for WKInterfaceGroup

Owen Hartnett
 

Hi all:

I have the following properties in my Watch App Extension:

@property (weak, nonatomic) IBOutlet WKInterfaceGroup *topGroup;
@property (weak, nonatomic) IBOutlet WKInterfaceGroup *bottomGroup;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *topScoreLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *bottomScoreLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *topLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *bottomLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *gameScore;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *topButton;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *bottomButton;

The above are all connected to the proper places in the Watch App storyboard.  All of them, when the WKInterfaceController is loaded, are populated with values,
EXCEPT the two WKInterfaceGroup at the top. They have a null value.

I want to programmatically change the background color of the groups, which I can do in Interface Builder, but without Xcode returning a reference to the group, it’s impossible.

Here’s the object hierarchy in Interface Builder

Top Button
Group
Top Label
TopScoreLabel
Separator
Bottom Button
Group
Bottom Label
BottomScoreLabel

Could it be because the Group is a subview of the Button?  

Or should I report this as a bug?

-Owen


Re: .xcconfig not being used for prefix header

Sak Wathanasin
 



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


.xcconfig not being used for prefix header

John Brownie
 

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Undefined symbols for architecture arm64

Walter McCreary
 

Thanks, Alex.

My architectures build settings do match yours.

This is an old project, originating in 2009. There are 7 targets, and this behavior is common to at least 2 of them. At least one of them (the newest, from 2014) is okay. So, I’m assuming that the project build settings aren’t problematic.

Since my last email, I tried building the target in question after updating the .LinkFileList by hand, to include the new classes that the linker could not find previously. This worked, and the build for arm64 succeeded (though it did not touch or update the .LinkFileList).

I also tried a build without a .LinkFileList, to see if that would force its generation, but this failed, with the linker complaining that it couldn’t find the file. So, I’m guessing that the compiler must be responsible for generating that list for the linker. Do you know if that’s the case?

Anyway, I decided to just mv the project’s build directory out of the way, to force rebuilding the whole tree. This has tested ok for one of the targets in question - I have not yet tested any of the others.

-Walter

On Jul 19, 2019, at 21:30, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

Yeah, in build settings, what are your settings for Valid Architectures?

Just enter Architectures in the search field in Build Settings and that should help.

I’ve got these on one of my projects.

arm64 arm64e armv7 armv7s

Also, for Architectures, do you have this?
$(ARCHS_STANDARD)




On Jul 19, 2019, at 4:48 PM, Walter McCreary <walt@gigs.com> wrote:

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter









Re: Undefined symbols for architecture arm64

Alex Zavatone
 

Yeah, in build settings, what are your settings for Valid Architectures?

Just enter Architectures in the search field in Build Settings and that should help.

I’ve got these on one of my projects.

arm64 arm64e armv7 armv7s

Also, for Architectures, do you have this?
$(ARCHS_STANDARD)

On Jul 19, 2019, at 4:48 PM, Walter McCreary <walt@gigs.com> wrote:

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter






Undefined symbols for architecture arm64

Walter McCreary
 

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter


Dynamic libraries in nonstandard locations - weak linking, or other solutions?

Jonathan Taylor
 

Hi all,

I’m having an involuntary adventure with the dynamic loader, as I attempt to link an ObjC code against anaconda python 3. (I worked out a solution for python 2.7 a while ago, but switching to python 3 has thrown up some more problems). The fundamental issue here is that there is a dynamic library “libpython3.5m.dylib” that my code must link against. That library lives in a nonstandard location and, depending on how anaconda was installed, it may be in a directory such as “/anaconda" or it may be in “~/anaconda” (which is even worse, as the path will vary from user to user). This nonstandard location is causing me a lot of grief!

At the moment there are several places where I have to customize the Xcode project file depending on the system that it’s sitting on:
- Path to the dylib as it appears in the file list and library search paths
- Header search paths
- Runpath search paths (so that the dylib location @rpath/libpython3.5m.dylib can be resolved at runtime)

The one that is really unfortunate is the runpath search path: if the built binary is copied to another machine (and anaconda lives in the user’s home folder) then the dylib will not be found on launch. Thus it’s not enough to customize the project file for the machine I am building on, it must be customized for the machine the binary will be run on.

I feel that there must be a solution to this - can anybody offer any advice about how to improve on the way I am handling this at the moment?

One thing I tried was to weak-link against the library, and load it myself from my code (at which point I can be a bit intelligent about figuring out where the dylib might actually be located on disk, on this particular machine). I don’t know if this is the best solution, but it seemed like a plausible one to me. This almost works. I can load the library using dlopen, and confirm that the symbol “Py_DecodeLocale” is present. However, when I actually call the function Py_DecodeLocale from my code, I get a runtime error “cannot resolve symbol _Py_DecodeLocale… because dependent dylib #2 could not be loaded”. I can fix this if I *do* specify a runpath search path in the project… but then I am back to hard-coding the location of the dylib at build time. Am I somehow missing something I need to do here? I would have expected that if I have loaded the library myself then I should be able to call the functions within it. Am I misunderstanding how weak linking is supposed to work?

[Note that the symbol reported as present by dlsym does NOT have a leading underscore, whereas the unresolvable symbol does. From my reading of the man pages, I think that is to be expected, but I’ll highlight it just in case it rings alarm bells for anyone…]


As you can see, I’m a bit lost with this - I am no expert on dynamic libraries, and am feeling my way around a bit in the hope of finding a “run-anywhere” solution that allows me to link to this dylib in a nonstandard location. Thanks for any suggestions.

Cheers
Jonny


Adding PDFKit palette to Xcode 10

Walter McCreary
 

I’m revising some iOS apps (for iOS 12.0) to use PDFView objects.  I have included the PDFKit framework, but the IB objects library does not contain  a PDFView.  PDFKit programming guide is out of date regarding adding the palette:

"A PDFView user interface element is available in Interface Builder, so you should use that wherever you want your application to display PDF content. Note that you need to install the PDF Kit palette in /Developer/Extras/Palettes/PDFKit.palette to make PDFViews available.
To add the PDFKit palette in Interface Builder, select the Palettes tab in the Preferences panel. Click the Add… button, navigate to the /Developer/Extras/Palettes folder, and select the PDFKit palette. Next, select the Customize Toolbar menu item in the Tools/Palettes menu and drag the PDFKit palette to the toolbar to make it visible. “
So, for Xcode 10, is there a way to add the PDFKit palette to the objects library?



promoting specific warnings to errors

yetanothermeagain
 

with obj-c / c / c++ compiler i was able to force specific warnings into errors on a "per warning" basis.

example, Xcode build console shows: "warning: unused variable 'i' [-Wunused-variable]"
i then take code in brackets and add it to "other warning" flags of Xcode:  -Werror=unused-variable
since then Xcode issues errors for this warning: "error: unused variable 'i' [-Werror,-Wunused-variable]"

note that i can do this per warning type, instead of a blank "-Werror" to force all warnings to be errors.

with swift compiler (and for some warnings in C/C++/Obj-C, presumably the new ones) i no longer see any code in brackets. is there a mechanism to achieve this behaviour, forcing specific warnings of my choice to be errors?


Re: NSDictionary == NSMutableDictionary #pragma

 

On Jul 7, 2019, at 11:05 PM, Marco S Hyman <marc@snafu.org> wrote:


is Xcode 12 beta already out?
Yes, it’s been out since WWDC a month ago. You can download beta 3 now; it’s pretty solid.
You’re off a digit. Current Xcode is 10.2.1. Beta Xcode is 11.0. 12 is still in the future.
*facepalm*
That’s what I get for emailing on my iPad. Sorry!

—Jens


Re: NSDictionary == NSMutableDictionary #pragma

Marco S Hyman
 

is Xcode 12 beta already out?
Yes, it’s been out since WWDC a month ago. You can download beta 3 now; it’s pretty solid.
You’re off a digit. Current Xcode is 10.2.1. Beta Xcode is 11.0. 12 is still in the future.

Marc


Re: NSDictionary == NSMutableDictionary #pragma

 

On Jul 7, 2019, at 5:01 AM, yetanothermeagain <gofennex@gmail.com> wrote:

is Xcode 12 beta already out?
Yes, it’s been out since WWDC a month ago. You can download beta 3 now; it’s pretty solid.

—Jens


Re: NSDictionary == NSMutableDictionary #pragma

yetanothermeagain
 


i tracked the difference down to this: "clang main.m -Werror -fobjc-arc"
the "-fobjc-arc" is the one that causes the trouble. and we can't create modern apps without using arc these days.

it looks like the apple responder to my bug report just didn't use the "-fobjc-arc" key, so it worked for him and thus he replied with "it works in" whatever version of Xcode / clang he happened to have on his machine without properly investigating the cause of the problem... i can see the same happening with Xcode 11 beta 2 (clang-1100.0.20.17). will update my bug report with this information.

is Xcode 12 beta already out?


Re: NSDictionary == NSMutableDictionary #pragma

yetanothermeagain
 


but when i build this exact source from terminal i am getting the warning (or error if warnings are treated as errors) as expected!


clang main.m -Werror

> main.m:10:13: error: incompatible pointer types passing 'NSDictionary **' to parameter of type

      'NSMutableDictionary **' [-Werror,-Wincompatible-pointer-types]

        foo(&dictionary);

            ^~~~~~~~~~~

main.m:3:32: note: passing argument to parameter 'mutableDictionary' here

void foo(NSMutableDictionary** mutableDictionary) {

                               ^

1 error generated.


clang version is this:

> clang -v
> Apple LLVM version 10.0.0 (clang-1000.11.45.5)

Target: x86_64-apple-darwin18.6.0

Thread model: posix

InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


and when I compile with Xcode i see the same path:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang


====================

#import <Foundation/Foundation.h>

 

void foo(NSMutableDictionary** mutableDictionary) {

    (*mutableDictionary)[@"hello"] = @"world";

}

 

int main(int argc, const char* argv[]) {

    @autoreleasepool {

        NSDictionary* dictionary = [NSDictionary new];

        foo(&dictionary);

    }

    return 0;

}

 


Re: NSDictionary == NSMutableDictionary #pragma

Steve Mills
 

On Jul 6, 2019, at 18:04, Jack Brindle via Groups.Io <jackbrindle=me.com@groups.io> wrote:

Is this really a bug?
Yes. Re-read the example. If the function takes NSMutableDictionary**, it should complain when you pass it an NSDictionary**, same as if it wants NSMutableDictionary* and you pass it NSDictionary*.

The opposite, however, is perfectly fine and correct; passing an NSMutableDictionary (with any number of splats) to a function that wants an NSDictionary. That’s how subclassing works.

Steve via iPad

621 - 640 of 1447