Date   

Hello

Akifumi Takata
 

Dear all,

My name is Akifumi Takata.

Regards,
Akifumi Takata


Re: LInker errors where there were none before

Alex Zavatone
 

Did you try removing and re-adding the linked binary?

It could be that the changes required for the newer versions to work would not function because of an API change if you wanted it to work on 10.8. If you try setting it to 10.9, then 10.10 as you mentioned, it starts working at 10.10, so there was an API change that was triggered by something you changed recently and the API needed is not in the currently linked binary for the CGToneGenerator when you target earlier than 10.10.

Or at least Xcode thinks this.

Argh, man.

If it weren’t 1:15 AM, I’d offer to spool up a VM and test on 10.12.6 in Xcode 8.3.3 and 9 to see if I could see what it might be.

On Oct 24, 2017, at 10:17 PM, Graham Cox <graham@...> wrote:

Thanks,

I have managed to get it working, but the reason is something of a mystery.
Xcode 9 showed the same problem, so that wasn’t it. I created a new project and just added the CCToneGenerator class to it (which is where the calls to Audio Toolbox are made). It compiled, linked and worked fine.

I worked through the build settings for each to see what differed. The only one was deployment target - 10.8 for the failing build, 10.13 for the working one. Changing it to 10.13 compiled, linked and worked fine. The earliest deployment target that works is 10.10. This is the mystery - when I previously built this project it targeted 10.8 and that worked fine. The APIs in question are marked as being available from 10.6.

For this project, targeting 10.10 as a minimum is not a problem, but I can’t understand why it can’t target 10.8 as before.

Any ideas?

—Graham




On 25 Oct 2017, at 12:21 pm, Roland King <rols@...> wrote:

what I usually do to debug these things is pull the link line from the detailed build log, go to the same directory, run it by hand and ensure I see the same result.

Then I start hunting along the command line to ensure the AudioToolbox is really being linked and where it's coming from, then go and check the package to make sure it contains the symbols I need.

You might want (by hand) to also try then shuffling AudioToolbox later in the link line to see if you have a link order issue (CCToneGenerator linked after AudioToolbox). if you can get it going by hand, then go back to Xcode and see what you can do to make it generate a working link line.



Re: LInker errors where there were none before

Graham Cox
 

Thanks,

I have managed to get it working, but the reason is something of a mystery.
Xcode 9 showed the same problem, so that wasn’t it. I created a new project and just added the CCToneGenerator class to it (which is where the calls to Audio Toolbox are made). It compiled, linked and worked fine.

I worked through the build settings for each to see what differed. The only one was deployment target - 10.8 for the failing build, 10.13 for the working one. Changing it to 10.13 compiled, linked and worked fine. The earliest deployment target that works is 10.10. This is the mystery - when I previously built this project it targeted 10.8 and that worked fine. The APIs in question are marked as being available from 10.6.

For this project, targeting 10.10 as a minimum is not a problem, but I can’t understand why it can’t target 10.8 as before.

Any ideas?

—Graham

On 25 Oct 2017, at 12:21 pm, Roland King <rols@...> wrote:

what I usually do to debug these things is pull the link line from the detailed build log, go to the same directory, run it by hand and ensure I see the same result.

Then I start hunting along the command line to ensure the AudioToolbox is really being linked and where it's coming from, then go and check the package to make sure it contains the symbols I need.

You might want (by hand) to also try then shuffling AudioToolbox later in the link line to see if you have a link order issue (CCToneGenerator linked after AudioToolbox). if you can get it going by hand, then go back to Xcode and see what you can do to make it generate a working link line.


Re: LInker errors where there were none before

Roland King
 

what I usually do to debug these things is pull the link line from the detailed build log, go to the same directory, run it by hand and ensure I see the same result.

Then I start hunting along the command line to ensure the AudioToolbox is really being linked and where it's coming from, then go and check the package to make sure it contains the symbols I need.

You might want (by hand) to also try then shuffling AudioToolbox later in the link line to see if you have a link order issue (CCToneGenerator linked after AudioToolbox). if you can get it going by hand, then go back to Xcode and see what you can do to make it generate a working link line.


On 25/10/2017 08:34, Graham Cox wrote:

All looks OK.

I’m going to try Xcode 9, just in case (grasping at straws perhaps). I did upgrade Xcode and the OS separately, but this particular project wasn’t recompiled until now.

—Graham





On 25 Oct 2017, at 10:45 am, Alex Zavatone <zav@...> wrote:

It sounds like the one of a few things might help.

Look in your "link to binaries” build section to see if any binaries are added twice, or are missing.

Also, check to see in the build file phases that you’re not adding the .m file twice under Compile Sources. 

I’ve seen Xcode return an error like this, but really, it was that there were two attempts to build the file with the same methods and it said that it couldn’t link, not that the same file was included twice in the compile process.

I’d check that before attempting to reinstall Xcode 8.3.3.





Re: LInker errors where there were none before

Graham Cox
 

All looks OK.

I’m going to try Xcode 9, just in case (grasping at straws perhaps). I did upgrade Xcode and the OS separately, but this particular project wasn’t recompiled until now.

—Graham

On 25 Oct 2017, at 10:45 am, Alex Zavatone <zav@...> wrote:

It sounds like the one of a few things might help.

Look in your "link to binaries” build section to see if any binaries are added twice, or are missing.

Also, check to see in the build file phases that you’re not adding the .m file twice under Compile Sources.

I’ve seen Xcode return an error like this, but really, it was that there were two attempts to build the file with the same methods and it said that it couldn’t link, not that the same file was included twice in the compile process.

I’d check that before attempting to reinstall Xcode 8.3.3.


Re: LInker errors where there were none before

Alex Zavatone
 

It sounds like the one of a few things might help.

Look in your "link to binaries” build section to see if any binaries are added twice, or are missing.

Also, check to see in the build file phases that you’re not adding the .m file twice under Compile Sources.

I’ve seen Xcode return an error like this, but really, it was that there were two attempts to build the file with the same methods and it said that it couldn’t link, not that the same file was included twice in the compile process.

I’d check that before attempting to reinstall Xcode 8.3.3.


FYI, since we don’t know if High Sierra is part of the problem or not, this is why I always install major OS and Xcode upgrades to a clone of my working OS, or in a VM which is a clone of my working OS.

I went through issues with High Sierra and MacOS Server for High Sierra a few weeks back that only became apparent a day or so after I did the upgrade and started working with it that the upgrade sucked and removed the nice Git hosting option from MacOS Server.

Now, I have a 25 GB VM image of 10.12.6, Xcode 9.0 and Server 5.3 that I can duplicate, start up the cloned VM, upgrade and rename, work with it and see if it’s worth moving forward with the upgrade without destabilizing my working environment.

If it sucks (it did) I can just throw the copy away, but I can keep the working image to duplicate again for the next set of upgrades.

Good luck.
Alex Zavatone

On Oct 24, 2017, at 6:22 PM, Graham Cox <graham@...> wrote:

I’m using 8.3.3 ;)

Yes, that was an update! Maybe I should try 9, but somehow an issue like this doesn’t quite seem like an Xcode problem.

—Graham



On 25 Oct 2017, at 9:30 am, Alex Zavatone <zav@...> wrote:

Which version of Xcode?

I haven’t had problems with Xcode 9.0, but 9.0.1 was released and some people are reporting various errors.

Are you using 9.0 or 9.0.1?



Re: LInker errors where there were none before

Graham Cox
 

I’m using 8.3.3 ;)

Yes, that was an update! Maybe I should try 9, but somehow an issue like this doesn’t quite seem like an Xcode problem.

—Graham

On 25 Oct 2017, at 9:30 am, Alex Zavatone <zav@...> wrote:

Which version of Xcode?

I haven’t had problems with Xcode 9.0, but 9.0.1 was released and some people are reporting various errors.

Are you using 9.0 or 9.0.1?


Re: LInker errors where there were none before

Alex Zavatone
 

Which version of Xcode?

I haven’t had problems with Xcode 9.0, but 9.0.1 was released and some people are reporting various errors.

Are you using 9.0 or 9.0.1?

On Oct 24, 2017, at 5:19 PM, Graham Cox <graham@...> wrote:

Hi all,

I’m suddenly running into some linker errors against AudioToolbox on a project after upgrading Xcode and installing High Sierra (not sure which of these did it).

Undefined symbols for architecture x86_64:
"_AudioComponentFindNext", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioComponentInstanceDispose", referenced from:
-[CCToneGenerator dealloc] in CCToneGenerator.o
"_AudioComponentInstanceNew", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioOutputUnitStart", referenced from:
-[CCToneGenerator setEnabled:] in CCToneGenerator.o
"_AudioOutputUnitStop", referenced from:
-[CCToneGenerator stop] in CCToneGenerator.o
"_AudioUnitInitialize", referenced from:
-[CCToneGenerator setEnabled:] in CCToneGenerator.o
"_AudioUnitSetProperty", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioUnitUninitialize", referenced from:
-[CCToneGenerator stop] in CCToneGenerator.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I’m linking against AudioToolbox, the source code includes the headers and the ‘Jump to Definition’ finds the declaration in the header OK. The functions are not deprecated and the project built just fine last time I tried it (which was some months ago on a different Xcode/OS version). When building the project, Xcode did not prompt to update any build settings as it usually does after an update.

Any ideas what could be causing this?


—Graham





LInker errors where there were none before

Graham Cox
 

Hi all,

I’m suddenly running into some linker errors against AudioToolbox on a project after upgrading Xcode and installing High Sierra (not sure which of these did it).

Undefined symbols for architecture x86_64:
"_AudioComponentFindNext", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioComponentInstanceDispose", referenced from:
-[CCToneGenerator dealloc] in CCToneGenerator.o
"_AudioComponentInstanceNew", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioOutputUnitStart", referenced from:
-[CCToneGenerator setEnabled:] in CCToneGenerator.o
"_AudioOutputUnitStop", referenced from:
-[CCToneGenerator stop] in CCToneGenerator.o
"_AudioUnitInitialize", referenced from:
-[CCToneGenerator setEnabled:] in CCToneGenerator.o
"_AudioUnitSetProperty", referenced from:
-[CCToneGenerator createToneUnit] in CCToneGenerator.o
"_AudioUnitUninitialize", referenced from:
-[CCToneGenerator stop] in CCToneGenerator.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I’m linking against AudioToolbox, the source code includes the headers and the ‘Jump to Definition’ finds the declaration in the header OK. The functions are not deprecated and the project built just fine last time I tried it (which was some months ago on a different Xcode/OS version). When building the project, Xcode did not prompt to update any build settings as it usually does after an update.

Any ideas what could be causing this?


—Graham


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

 



On Oct 20, 2017, at 10:15 AM, Quincey Morris <quinceymorris@...> wrote:

However, what I really wanted to say is that precompilation may still be useful *within* a large module such as the main application target.

Yup. When the target you’re building has enough of its own header files to affect compilation speed, it becomes useful to precompile them.

There are also a lot of C and C++ headers in the OS (and in external libraries) that aren’t packaged into modules. For example, <sqlite3.h> is 10,000 lines long and it definitely helps to precompile it.

—Jens


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Quincey Morris
 

On Oct 20, 2017, at 07:29 , Fritz Anderson <anderson.fritz@...> wrote:

The answer should be no because the effect of a chain of #includes depends on the order they're done.

Except of course that the tradition of *pure C* programming has assimilated this as standard programming technique: the compilation of one package is modified by pre-inserting macro definitions that modify the outcome of the package’s own macro definitions. Indeed, the use of environment variables as macros available to the compiler is much the same thing.

However, what I really wanted to say is that precompilation may still be useful *within* a large module such as the main application target. In that case, there may be a standard set of imports used in most source files, comprising multiple modules as well as multiple header files, and it *may* be beneficial to precompile all of that into a single, loadable file.

I think a more accurate statement about precompiled headers would say:

— Module inclusion is probably preferable to precompilation of the same declarations.

— Precompilation of non-module (i.e. intra-target) declarations is of no use to Swift code because it doesn’t have monolithic, linear compilations like C does.


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Fritz Anderson
 

I want faster builds. We all want faster builds. The question is whether precompiling text-substituted inclusions is the best we can do with a modern development system.

The answer was yes when lexical insertion was the only way to impart context to a C-family source file. The answer should be no because the effect of a chain of #includes depends on the order they're done. If a.h says

#ifndef FOO
    #undef FOO
    #define FOO bar
#end

and b.h says

#ifndef FOO
    #undef FOO
    #define FOO baz
#end

Then it's really important (and impossible to document and surely intractable to debug) the order in which they are #included. Modules are precompiled and versioned against the environment in which that happened. Macro conflicts within a module are "ill-formed" and across modules they're local.

Caveat that I'm drawing the details from memory and a cursory review of http://releases.llvm.org/3.5.0/tools/clang/docs/Modules.html . Further discussion should address the LLVM release note, not my memory.

    — F

On Oct 19, 2017, at 6:04 PM, Steve Mills <sjmills@...> wrote:

Why wouldn’t you want faster builds?


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Steve Mills
 

On Oct 19, 2017, at 17:11, Jens Alfke <jens@...> wrote:

On Oct 19, 2017, at 12:11 PM, Alex Zavatone <zav@...> wrote:

I understand that a .pch is now a “bad idea”. OK. What do we do instead? Why?
Wait, what? I never got the memo on this.

The precompiled prefix header is just to speed up builds.
Exactly. I’ve never heard anyone say they should no longer be used. Why wouldn’t you want faster builds?

Steve via iPad


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

 

On Oct 19, 2017, at 12:11 PM, Alex Zavatone <zav@...> wrote:

I understand that a .pch is now a “bad idea”. OK. What do we do instead? Why?
Wait, what? I never got the memo on this.

Is it good practice to create one constants.h/m? Or is that just another way of masking a global (which is bad)?
I put constants in the headers for the classes/APIs they are used with. If you look at Cocoa headers you can see Apple does the same thing.

Also, this is a separate issue from whether to use a prefix or precompiled header. Ideally your code should be buildable without a prefix header, i.e. every source file should #import the headers it depends on. The precompiled prefix header is just to speed up builds.

—Jens


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Bernie Maier
 

Alex Zavatone:

I understand that a .pch is now a “bad idea”. OK. What do we do
instead? Why?
Pre-compiled headers are now considered to be a bad idea, yes, but although traditionally the *prefix* header was usually pre-compiled it doesn't have to be. So what I use in some of my project is a prefix header that simply isn't pre-compiled.

That said, I use it *extremely* sparingly, kind of like a more SCM-friendly place to define constants like conditional compilation flags that need to consistent across an entire build. These are often supplied as -D arguments to the compiler, and thus often live in relative obscurity amongst other project settings.

Like others, I would normally attach more specific constants to whatever they are most related to.


Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Alex Zavatone
 

Thanks Steve.  That’s one option I’ve been considering.  It’s a balance between knowing where to look for everything and properly scoping some constant to the one place where I use it. If there’s one thing that wastes my time, it’s hunting through my project for a constant, but if it only needs to be in one place, then I probably should learn to expect looking for it in the class that uses it.  

FYI, if anyone needs a little more explanation of how to handle this with modules, I just found this relatively recent link that may help us stay current.


It mentions how to use the umbrella header within modules if you’re using them.  

Also Ash Furrow has some good input.


Thanks for your time everyone.

- Alex Zavatone

On Oct 19, 2017, at 2:54 PM, Steve Christensen <punster@...> wrote:

I use constants a lot, but I put their declarations and definitions into the "owner" class files. For example if one object sources notifications and others consume them.

Foo.h

extern NSString* const __nonnull FooNotification;


Foo.m

NSString* const FooNotification = @"FooNotification";


With Obj-C I have rarely ended up with true globals since I can create singletons as "global" instances of particular classes.

I have created .h files containing some #defines that are used to conditionally compile certain features that may not be quite ready for primetime and so it could get pulled before an app ships.

Steve


On Oct 19, 2017, at 12:11 PM, Alex Zavatone <zav@...> wrote:

I’ve read the Apple docs and looked around and can’t find definitive sources on what the preferred method is and how to do it.

Do we use modules?  If so, how?

I understand that a .pch is now a “bad idea”.  OK.  What do we do instead?  Why?

Is it good practice to create one constants.h/m?  Or is that just another way of masking a global (which is bad)?

It does make everything easy to find.

Should we create one .h/.m file with multiple constants classes within?

I can easily go back to using a .pch, but a clear path forward to the current year’s practice would be nice.

Thanks in advance.

- Alex Zavatone






Re: Objective-C: What is the current preferred method of declaring constants without a .pch?

Steve Christensen
 

I use constants a lot, but I put their declarations and definitions into the "owner" class files. For example if one object sources notifications and others consume them.

Foo.h

extern NSString* const __nonnull FooNotification;


Foo.m

NSString* const FooNotification = @"FooNotification";


With Obj-C I have rarely ended up with true globals since I can create singletons as "global" instances of particular classes.

I have created .h files containing some #defines that are used to conditionally compile certain features that may not be quite ready for primetime and so it could get pulled before an app ships.

Steve

On Oct 19, 2017, at 12:11 PM, Alex Zavatone <zav@...> wrote:

I’ve read the Apple docs and looked around and can’t find definitive sources on what the preferred method is and how to do it.

Do we use modules? If so, how?

I understand that a .pch is now a “bad idea”. OK. What do we do instead? Why?

Is it good practice to create one constants.h/m? Or is that just another way of masking a global (which is bad)?

It does make everything easy to find.

Should we create one .h/.m file with multiple constants classes within?

I can easily go back to using a .pch, but a clear path forward to the current year’s practice would be nice.

Thanks in advance.

- Alex Zavatone


Objective-C: What is the current preferred method of declaring constants without a .pch?

Alex Zavatone
 

I’ve read the Apple docs and looked around and can’t find definitive sources on what the preferred method is and how to do it.

Do we use modules? If so, how?

I understand that a .pch is now a “bad idea”. OK. What do we do instead? Why?

Is it good practice to create one constants.h/m? Or is that just another way of masking a global (which is bad)?

It does make everything easy to find.

Should we create one .h/.m file with multiple constants classes within?

I can easily go back to using a .pch, but a clear path forward to the current year’s practice would be nice.

Thanks in advance.

- Alex Zavatone


Re: Sandboxed WkWebView

Gerriet M. Denkmann
 

On 18 Oct 2017, at 12:21, Jens Alfke <jens@...> wrote:

On Oct 17, 2017, at 9:14 PM, Gerriet M. Denkmann <g@...> wrote:

I would never have guessed that an app which does not use any outgoing connections at all needs this entitlement.
It sounds like the framework is being too eager to check for this entitlement. It’s definitely worth filing a bug report with Apple!

—Jens
The reason that I took all this trouble with sandboxing is:

In iOS 11 this shows a cat:

htmlString = <h1>Cat</h1><img alt=“Cat” src=“cat.gif” />
[wkWebView loadHTMLString: htmlString baseURL: folder containing cat.gif ]

In macOS 12.6 there was no cat, just a blue icon with “?”, probably meaning broken link.
So I thought: iOS is sandboxed, so maybe WkWebView needs sandboxing to show cats.

But now with sandboxing on macOS I still do not see a cat.
Most frustrating.

Gerriet.


Re: Sandboxed WkWebView

 



On Oct 17, 2017, at 9:14 PM, Gerriet M. Denkmann <g@...> wrote:

I would never have guessed that an app which does not use any outgoing connections at all needs this entitlement.

It sounds like the framework is being too eager to check for this entitlement. It’s definitely worth filing a bug report with Apple!

—Jens

1141 - 1160 of 1516