Loader warning: visibility settings

posted on 20120228

Problem: XCode 4.2.1 loader issues this warning:

ld: warning: direct access in __ZN9__gnu_cxx26__concurrence_unlock_errorC2Ev to global weak symbol __ZTVN9__gnu_cxx26__concurrence_unlock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

Fix: In project (or product) settings, look for "Code Generation" > "Hidden Local Variables". Set this to "No" and build the project again. Works for me.

Navigating the search path jungle

posted on 2008-06-02 11:35:08

Problem: The relationships between the various search path settings baffle me. There are Preference panels for both the Target and the Project (can’t figure out which has priority over the other); within those there are settings for the SDK Path and Library Search Paths. When I try to link to a library (say, xyz.dylib) in /usr/local/lib, it appears that it is not sufficient to simply add this path to the Library Search Paths: the link editor complains that it can’t find /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/xyz.dylib . No surprise there, because the SDK Path setting says that the SDK path is prepended before all library paths. But when I put "../../../usr/local/lib" in Library Search Paths, the linker complains that it can’t find "../../../usr/local/xyz.dylib." Huh? Where’s the prepend? Harrumph.

Kludge: Put "/usr/local/lib" in Library Search Paths and create a symbolic link to that directory:

% cd /Developer/SDKs/MacOSX10.4u.sdk/usr % ln -s /usr/local ./local

XCode’s linker now finds the library OK.

Compiler: type ‘std::deque....’ is not derived from ‘...’

posted on 2008-06-02 11:35:42

Compiler error:

error: type ‘std::deque<T_Shell<T>::builtin, std::allocator<T_Shell<T>::builtin> >’ is not derived from type ‘T_Shell<T>’

Fix: Change

typedef deque<builtin>::const_iterator cBuiltinIterator;

To:

typedef typename deque<builtin>::const_iterator cBuiltinIterator;

Compiler error: template with C linkage

posted on 2008-06-02 11:35:42

Compiler error:

error: template with C linkage

Fix: move /usr/include to somewhere else (e.g., ~/src/usr_include) and edit XCode’s header search path accordingly (Project > Edit project setttings > Build > Collection: Search paths > Header search paths).

Loader: cputype mismatch?

posted on 2007-02-01 20:54:07

Problem: Loader complains about an architecture mismatch between the project and a dynamic library:

/usr/bin/ld: warning /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libsndfile.1.0.17.dylib cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)

This error does not appear with the Debug build; only with the Release build. And I swear I never did an i386 build (why would I want to??).

Fix: Clean the project (both the Debug and Release). In the Project Settings, choose the Architectures setting and set it to "ppc i386". Rebuild. Clean again. Now change the setting back to "ppc". Rebuild. Success! — just don’t ask me why.

Follow-up [071110]: Mike V sent in the following info:

I had the same problem when linking "-arch i386" while trying to link with ppc only dynamic library; I tried your sulution but still was getting i386 as a separate build.

I tried changing Project Settings -> Cross-Develop Using Target: from 10.4 (Universal) to Current Mac,it still gave me a list of undefined symbols i was able to pass a number of files that has been compiled.

What fixed the problem when i did

grep -R ’i386’ my_pro..xcodeproj

and found the line with ARCH, which is also mentioned in here.

here is the line(s):

... /* Release */ = { isa = XCBuildConfiguration; buildSettings = { ARCHS = ( ppc, i386, );

Removing/uncommenting i386 solves the problem!!! also if i comment it out xcode will remove the line afterwards by itself.

Apparently when i first open build options you have

Architectures set to "$(NATIVE_ARCH)"

Maybe what you can emphasize in your notes is that you need to double click these values NOT to enter them manually. e.g "ppc i386" instead of "$(NATIVE_ARCH) i386" which i have done, because it still displayed "ppc i386" after i clicked <enter> to end editing the Architectures field.

I would highly recommend updatin this information for your tutorial (not that i’ve discovered it, just that i was quite frustraded and dont want this for other people) 8D

Thanks, Mike!

Compiler: class ‘...’ has no field named ‘...’

posted on 2007-02-01 20:44:49

Compiler error:

error: class ’Gram’ does not have any field named ’T_Packet’

Change:

Gram :: Gram(string aName,int ns) : T_Packet(aName, Gram_PACKET_TYPE, Gram_WORDTYPENAME, Gram_PACKET_DESC, Gram_PACKET_EXT) { ... }

To:

Gram :: Gram(string aName,int ns) : T_Packet<Gram_DATATYPE>(aName, Gram_PACKET_TYPE, Gram_WORDTYPENAME, Gram_PACKET_DESC, Gram_PACKET_EXT) { ... }

Compiler: conflicting types for built-in function ‘scalb’

posted on 2007-02-01 20:43:45

Compiler error: conflicting types for built-in function ’scalb’

Fix: Ignore it. This appears to be a known issue with the Apple SDK.

When the debugger or compiler start acting flaky

posted on 2007-02-01 00:00:33

Now and then the debugger starts acting flaky, losing track of breakpoints and wandering all over the place, no matter how you step into, over, or out the code. At other times, the compiler starts going wild.

Fix: Try one or more of these:

1. Quit XCode, relaunch, and try again.
2. Clean, rebuild, and try again.
3. Create a new project from scratch, copy all the source files into the new project, and try again.

FWIW, #3 is the only one that works reliably for me.

No stdin when debugging a C++ command line utility?

posted on 2007-02-01 00:00:11

Problem: Can’t enter keyboard input when debugging a C++ command line utility.

Fix: Select Debug->Standard I/O Log. Output will appear in the "Standard I/O" window. You can type tty input there.

How to import libsndfile into a project

posted on 2007-01-10 00:00:37

libsndfile is an open-source C library to allow programmers to read and write sound files via a simple, standard interface. It handles many formats: WAV, AIFF, Octave, PAF, etc. You, the programmer, don’t have to worry about the dirty business of headers, endian-ness, etc. — libsndfile takes care of all that invisibly. Getting libsndfile to work with XCode projects is fairly straightforward, but in case you (like me) are never quite sure what you’re doing, the following overview may be helpful. Note: By default, the Finder hides root-level directories (/usr, /lib, /etc, etc.,) from dialog boxes. To work with libraries like libsndfile, you have to make them visible.

1. Compile libsndfile according to the instructions in the README and INSTALL files. Note that the default installation puts sndfile.h in /usr/local/include, and the library itself in /usr/local/lib.
2. Create a new XCode project
3. Copy make_sin.c from the libsndfile "examples" directory into your project.
4. Tell XCode where to find the include file:
   • Project → Edit Project Settings
   • Click "Build"
   • In "Collection" popup, select "Search Paths"
   • Double-click "Header Search Paths" and add the path /usr/local/include if it’s not already listed there. Leave the "Recursive" checkbox unchecked.
   • Click "OK".
   • Double-click "Library Search Paths" and add the path /usr/local/lib if it’s not already listed there. Leave the "Recursive" checkbox unchecked.
   • Click "OK"
   • Close the Project Info window.
5. Add the library to your project:
   • In the project window, select the project icon in the "Groups and Files" pane.
   • Project → Add to Project... (or control-click the project icon).
   • Navigate to the library you wish to include (probably libsndfile.a. If you want to copy the library to your project (why would you??), click the checkbox. Click "Add."
6. Compile your project. You may have to do some minor tweaking to make_sin.c to get it to compile. For example, I had to change this: int main (void) to this: int main (int argc, char * const argv[])

That’s all there is to it.

XCode keyboard shortcuts

posted on 2007-01-01 00:00:33

to do this...	...type this
toggle between source code and include files	Cmd-Opt-UpArrow

Don’t use ZeroLink!

posted on 2007-01-01 00:00:19

With ZeroLink turned on, the program executes, then aborts:

ZeroLink: unknown symbol ’__ZN7T_ShellI9WorkspaceEC1Ev’

With ZeroLink turned off, the build fails, but now the messages are a little more useful:

/usr/bin/ld: Undefined symbols: _AIFF_verbose T_Shell<Workspace>::Init() T_Shell<Workspace>::T_Shell() T_Shell<Workspace>::~T_Shell() SAC::SAC() SAC::~SAC() AIFF::AIFF() AIFF::~AIFF() ... ...{plus lots more}... ... collect2: ld returned 1 exit status

Moral: ZeroLink makes it hard to see what’s going on. Keep ZeroLink turned off so you can debug those loader errors.

How to include non- .h files

posted on 2007-01-01 00:00:18

Use care when include’ing non .h files in your source code. For example:

• #include "foo.h" resolves to foo.h, wherever it lives in your nested hierarchy of project dirs.
• #include "bar.cpp" resolves to ./bar.cpp. If it lives outside this directory, then give it a relative pathname: #include "../foo/bar.cpp"

How to move source files into a new project

posted on 2007-01-01 00:00:01

After creating a new project, open the project window. Right-click on the "Source" folder in the "Groups & Files" pane. Select Add → Existing Files... and navigate to the files you want to include.

When the popup window appears, check the Copy items into destination group’s folder box. Check the Recursively create groups... radio button. Click Add. Copies of the selected files will be placed in the project source directory.