Why Is My App Returning Hundreds of Errors That Say "Undefinedsymbol"

Xcode build fails due to Undefined symbol: __swift_FORCE_LOAD_$_swiftUIKit

As hinted by the warnings saying directory not found, it seems Xcode doesn't like having a space in its bundle's file name.

I renamed it from Xcode 11.0-Beta.2.app to Xcode-11.0-Beta.2.app and now it builds just fine.

What is an undefined reference/unresolved external symbol error and how do I fix it?

Compiling a C++ program takes place in several steps, as specified by 2.2 (credits to Keith Thompson for the reference):

The precedence among the syntax rules of translation is specified by the following phases [see footnote].
Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set
(introducing new-line characters for end-of-line indicators) if
necessary. [SNIP]
Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to
form logical source lines. [SNIP]
The source file is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). [SNIP]
Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. [SNIP]
Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name
in a character literal or a non-raw string literal, is converted to
the corresponding member of the execution character set; [SNIP]
Adjacent string literal tokens are concatenated.
White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token. (2.7). The
resulting tokens are syntactically and semantically analyzed and
translated as a translation unit. [SNIP]
Translated translation units and instantiation units are combined as follows: [SNIP]
All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the
current translation. All such translator output is collected into a
program image which contains information needed for execution in its
execution environment. (emphasis mine)
[footnote] Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.

The specified errors occur during this last stage of compilation, most commonly referred to as linking. It basically means that you compiled a bunch of implementation files into object files or libraries and now you want to get them to work together.

Say you defined symbol a in a.cpp. Now, b.cpp declared that symbol and used it. Before linking, it simply assumes that that symbol was defined somewhere, but it doesn't yet care where. The linking phase is responsible for finding the symbol and correctly linking it to b.cpp (well, actually to the object or library that uses it).

If you're using Microsoft Visual Studio, you'll see that projects generate .lib files. These contain a table of exported symbols, and a table of imported symbols. The imported symbols are resolved against the libraries you link against, and the exported symbols are provided for the libraries that use that .lib (if any).

Similar mechanisms exist for other compilers/ platforms.

Common error messages are error LNK2001, error LNK1120, error LNK2019 for Microsoft Visual Studio and undefined reference to symbolName for GCC.

The code:

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

will generate the following errors with GCC:

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

and similar errors with Microsoft Visual Studio:

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

Common causes include:

Failure to link against appropriate libraries/object files or compile implementation files
Declared and undefined variable or function.
Common issues with class-type members
Template implementations not visible.
Symbols were defined in a C program and used in C++ code.
Incorrectly importing/exporting methods/classes across modules/dll. (MSVS specific)
Circular library dependency
undefined reference to `WinMain@16'
Interdependent library order
Multiple source files of the same name
Mistyping or not including the .lib extension when using the #pragma (Microsoft Visual Studio)
Problems with template friends
Inconsistent UNICODE definitions
Missing "extern" in const variable declarations/definitions (C++ only)
Visual Studio Code not configured for a multiple file project
Errors on Mac OS X when building a dylib, but a .so on other Unix-y systems is OK

Xcode build failure Undefined symbols for architecture x86_64

It looks like you are missing including the IOBluetooth.framework in your project. You can add it by:

Clicking on your project in the upper left of the left pane (the blue icon).
In the middle pane, click on the Build Phases tab.
Under "Link Binary With Libraries", click on the plus button.
Find the IOBluetooth.framework from the list and hit Add.

Sample Image

This will make sure that the IOBluetooth.framework definitions are found by the linker. You can see that the framework is a member of your target by clicking on the framework in the left pane and seeing the framework's target membership in the right pane (note I've moved the framework under the Frameworks group for organization purposes):

Sample Image

Undefined Symbol: Class::Class() error in C++. How can I fix this?

I guess the SportTicket constructor must call the super constructor with the appropriate arguments:

//Constructor
SportTicket(const char* RowSport, const char* SeatNumberSport):
ShowTicket(RowSport,SeatNumberSport),
beer_sold_check{false}
{}

PS you don't have to declare additional attributes RowSport and SeatNumberSport, just declare row and seat_number as protected instead of private, and they will be accessible from the SportTicket class.

Linking error: Undefined Symbols, lots of them (cpp cross compiling)

Seems you are trying to link C++ code with a C (gcc) linker call. That'll not include the appropriate libraries which is just what you are seeing. Try g++ instead of gcc (or throw out the C++ code/libraries).

ImportError: undefined symbol: fftw_execute

link_directories(${FFTW3F_LIBRARY_DIRS})

is not a great idea; you need to link to the library, not just tell the linker that the directory containing the libraries might also be interesting.

Instead, you use the modern CMake interface for linking libraries: that already tells CMake to link and how to find the libraries at link-time. Great! You can just remove this link_directories line.

The problem here is that you link against FFTWf (note the f: single precision, which is usually more than enough for SDR applications!), but use some double precision routines. Use fftwf_execute, and fftwf_complex!

This is just a unnecessarily complicated way of copying of memory:

      for(int i = 0; i < d_N; i++)
      {
        d_input[i][0] = in[i].real();
        d_input[i][1] = in[i].imag();
      }

The gr_complex type is just real, imaginary parts right after each other, exactly identical to fftwf_complex. Plan your DFT to allow you to select your input memory, instead of having to copy data into the fixed position.

Even more comfortably: remove all your own FFTW(f) handling, and just use gr::fft::fft_complex_rev, which does all this for you:

In your Kurtosis_c_impl.h:

#include <gnuradio/fft/fft.h>
…
class Kurtosis_c {
…
   fft::fft_complex_rev d_fft;
…
};

in your Kurtosis_c_impl.cc:

…
// constructor gets shorter :)
Kurtosis_c_impl::Kurtosis_c_impl(int fftsize) //should be unsigned int, by the way
      : gr::sync_block("Kurtosis_c",
              gr::io_signature::make(1, 1, sizeof(gr_complex)),
              gr::io_signature::make(0, 0, 0)),
              d_N(fftsize),
              d_fft(fftsize) {}
…
// work function:
    int
    Kurtosis_c_impl::work(int noutput_items,
        gr_vector_const_void_star &input_items,
        gr_vector_void_star &output_items)
    {
      const gr_complex *in = (const gr_complex*) input_items[0];
      for(unsigned int idx = 0; idx < d_N; ++idx) {
        d_fft.get_inbuf()[idx] = in[idx];
      }
      d_fft.execute();

regarding:

      for(int i = 0; i < d_N; i++)
      {   
        S1[i][0] = S1[i][0] + d_input[i][0];
        S1[i][1] = S1[i][1] + d_input[i][1];

You do realize that with complex numbers in C++, you can just do complex arithmetics? If your S1 is an array/vector/other container of gr_complex (which is just an alias for std::complex<float>, which is, given the inclusion order, just the same as fftwf_complex), then this boils down to

for(unsigned int i = 0; i < d_N; ++i)
{
  S1[i] += d_input[i];
}

Writing readable code is kind of important! In this case it's OK, especially because you're afterwards doing higher powers of the real and imaginary parts of d_input, anyways.

However,

        dc[i][0] = dc[i][0] + 1;
        dc[i][1] = dc[i][1] + 1;

Come one. That's just wasteful. Instead of increasing a number by +1, N times, just increase it by N, once.

      for(int i = 0; i < d_N; i++)
      {
        K[i][0] = (Myu4[i][0] - 4 * Myu3[i][0] * Myu1[i][0] + 6 * Myu2[i][0] * Myu1[i][0] 
               * Myu1[i][0] - 3 * Myu1[i][0] * Myu1[i][0] * Myu1[i][0] * Myu1[i][0]) / 
                ((Myu2[i][0] - Myu1[i][0] * Myu1[i][0]) * (Myu2[i][0] - Myu1[i][0] 
                  * Myu1[i][0]));
  
        K[i][1] = (Myu4[i][1] - 4 * Myu3[i][1] * Myu1[i][1] + 6 * Myu2[i][1] * Myu1[i][1] 
               * Myu1[i][1] - 3 * Myu1[i][1] * Myu1[i][1] * Myu1[i][1] * Myu1[i][1]) / 
                ((Myu2[i][1] - Myu1[i][1] * Myu1[i][1]) * (Myu2[i][1] - Myu1[i][1] 
                  * Myu1[i][1]));
      }

Honestly, this is unreadable, and you and your supervisor will curse you next week, when either of you try to read this.

      for(int i = 0; i < d_N; i++)
      {
        const auto& M1 = Myu1[i];
        const auto& M2 = Myu2[i];
        const auto& M3 = Myu3[i];
        const auto& M4 = Myu4[i];
        K[i].real() = (M4.real() - 4 * M3.real() * M1.real()  //comment on what this is
               + 6 * M2.real() * M1.real() * M1.real()  // comment
               - 3 * M1.real() * M1.real() * M1.real() * M1.real() /  // comment
                ((M2.real() - M1.real() * M1.real()) * (M2.real() - M1.real() * M1.real())); //comment
  
        K[i].imag() = /* This seems to be the exact same thing as above.
                          Clear indication that you should write a small inline
                          function that takes four float arguments and 
                          returns a flow to do this */
      }

Note that this literally yields the same machine code as your way of writing it, as these .real() and .imag() functions just compile to the same memory access. And references like M1… M4 are just logical sugar and also have no overhead.

Most importantly,

  // Tell runtime system how many output items we produced.
  return noutput_items;

You didn't read that comment! You're not returning the number of items you've produced (which is the same as you produced). You act as if you used all the input, even if you just used d_N! You're not even checking whether you have at least d_N input items. That is necessary. GNU Radio will give you a varying amount of input items, not always the same number!

Including one Xcode project in another -- linker errors

I assume the child project is a static library. Currently, your parent project knows how to find the header files of the child project (otherwise it wouldn't compile), but it doesn't know that it has to link to the library (.a) file of the child project.

You should probably add the library file to Targets > {your app} > Link Binary with Libraries. Furthermore, you probably need to add the linker flags -ObjC and possibly -all_load.

There are many detailed descriptions on the net, e.g. Build iPhone static library with Xcode.

Update:

If it's not a static library, then it's a rather strange project setup. The best thing you can do is to add the shared files (.h and .m) to both projects. They will then be independently compiled in both projects. That should work if you have few shared files.

But I recommend anyway to use a project setup with a static library. It nicely works if you properly set it up. I'm successfully using it. And - as I've told before - there a several good descriptions on the net how to set it up.

Undefined reference error but symbol existing in the library

The order of appearance of libraries matter.

To quote the online gcc manual

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.

You should be changing your compilation statement to

gcc -o myapp -Wall -L. myapp.c -ldynlib

to tell gcc to search for the symbols used in (compiled) myapp.c to be present in dynlib.