6 Replies Latest reply on Mar 13, 2007 5:42 PM by 807575

    linking: dwarf error: mangled line number section.

      I'm trying to get at 1st a unit test running (Suse 9.2, CC: Sun C++ 5.9 Linux_i386 Build35_2 2006/12/04). To keep things simple I start with only instantiation of a class of ccpunit:

      int main(int argc, char* argv[] )
      // Create the event manager and test controller
      CPPUNIT_NS::TestResult controller;

      In linking I get this error message:

      COM_TestMain.o(.text+0x10a3)/usr/bin/ld: Dwarf Error: mangled line number section.
      : In function `main':
      : undefined reference to `CppUnit::TestResult::TestResult(CppUnit::SynchronizedObject::SynchronizationObject*)'
      COM_TestMain.o(.text+0x10af): In function `main':
      : undefined reference to `CppUnit::TestResult::~TestResult()'
      dmake: Fatal error: Command failed for target `test.bin'

      I translated cppunit also from source level with sunstudio compiler, but it makes no difference. The mentioned symbols seems to be there (look into libcppunit.a with objdump). An interesting question also would be, why this lib (and others) only build the static targets?

      Does anybody know, what that error means and how to workaround? I'll also continue to find out and tell here in case of success.

      Ciao, Rolf
        • 1. Re: linking: dwarf error: mangled line number section.
          From the small amount of information you provided, it sounds like you have not compiled and linked all the needed definitions. The linker error message lists the functions that are missing. Be sure you compile all the associated source code and include the .o files in the link step.

          To say more, I would need to see the actual test case, with the source code and the actual command lines you are using.
          • 2. Re: linking: dwarf error: mangled line number section.

            Did you also build libcppunit with Sun CC? (I don't know SuSE too well, but I suspect that libcppunit could be a pre-installed package)

            I don't think that you can mix apps/libraries built with g++ and CC.

            • 3. Re: linking: dwarf error: mangled line number section.
              Paul is correct. You cannot mix g++ binaries with Sun C++ binaries. All the binaries must be produced by g++ or all by Sun C++.
              • 4. Re: linking: dwarf error: mangled line number section.
                yes I did compile cppunit with sunpro, because I already got that experience that libs can not be mixed between gcc and sunpro. Unfortunately I forgot that I also had an installed version from distribution DVD. But I linked with full path to the build version ,so I guess this is not the reason.
                But now I removed the installed version and will retry next week with that (had not much time this week).
                Ciao Rolf
                • 5. Re: linking: dwarf error: mangled line number section.
                  Ok, finally I got that working. The reason for unresolveds was a wrong sequence in link statement:
                  working: $(CC) $(ARC_FLAGS) $(OBJECTS) $(CPPUNITLIB) $(LIBS)
                  not working: $(CC) $(ARC_FLAGS) $(CPPUNITLIB) $(OBJECTS) $(LIBS)
                  for some reasons in solaris/sparc world this was no matter.

                  But there is another problem with syntax in $(CPPUNITLIB), to me these two statements should do same:
                  CPPUNITLIB = $(CPPUNIT_HOME)/lib/libcppunit.a
                  CPPUNITLIB = -L$(CPPUNIT_HOME)/lib -Bstatic -lcppunit
                  If I'm using the last one, I get the "dwarf error" and also lots of warnings like this appear:
                  /usr/bin/ld: Warning: size of symbol `std::string &std::string::operator=(constchar*)' changed from 482 in /opt/sunstudiomars/prod/lib/libCstd.a(instance.o) to 475 in /opt/sunstudiomars/prod/lib/libCstd.a(instance.o).

                  The first syntax does link without any errors or warnings. But the created binaray finally is doing its job (in both cases :-) .
                  Ciao, Rolf
                  • 6. Re: linking: dwarf error: mangled line number section.
                    The -Bstatic option is an order-sensitive directive. It means everything that follows on the command line will be linked statically.

                    -Bstatic should always be paired with -Bdyamic to avoid unintended consequences. Your second example should look like this:
                    CPPUNITLIB = -L$(CPPUNIT_HOME)/lib -Bstatic -lcppunit -Bdynamic

                    Even then, the two versions of the macro are not equivalent.

                    Puttting /path/to/mylib.a on the command line causes that specific library to be linked, and nothting else.

                    Putting -L/path/to causes the directory /path/to to be searched for every library that is not specified with its own path. If the directory contains somelib.a or somelib.so that is listed on the command line, you might get the wrong library.