From Fedora Project Wiki

Line 43: Line 43:


<code>magilla 49 % gcc -g -fPIC -c foo1.c foo2.c foo3.c
<code>magilla 49 % gcc -g -fPIC -c foo1.c foo2.c foo3.c
<code>magilla 50 % gcc -shared -o foo3.so foo3.o
<code>magilla 50 % gcc -shared -o foo3.so foo3.o
<code>magilla 51 % gcc -shared -o foo2.so foo2.o foo3.so
<code>magilla 51 % gcc -shared -o foo2.so foo2.o foo3.so
<code>magilla 52 % gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=
<code>magilla 52 % gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=


Line 52: Line 55:
New result:
New result:
<code>/usr/bin/ld: foo1.o: undefined reference to symbol 'foo'</code>
<code>/usr/bin/ld: foo1.o: undefined reference to symbol 'foo'</code>
<code>/usr/bin/ld: note: 'foo' is defined in DSO ./foo3.so so try adding it to the linker command line</code>
<code>/usr/bin/ld: note: 'foo' is defined in DSO ./foo3.so so try adding it to the linker command line</code>



Revision as of 21:59, 25 November 2009

Proposed changes to ld

Basics

The default behaviour for ld currently defaults to using the --add-needed flag. The proposed change would force the use of its complement, --no-add-needed.

What's the difference?

The big difference is that with the proposed change in place, ld will no longer skip linking needed libraries by default. The current default behaviour will lead ld to skip linking with a library if it is listed as a needed by another library that the program uses. In abstract terms, if libA is needed by libB and your program requires both libA and libB, your program may only link to libB. Then if another version of libB comes out that does not list libA as a needed library, then a recompilation will mysteriously break.

A concrete example from Roland McGrath:

libxml2.so has:

 NEEDED            Shared library: [libdl.so.2]
 NEEDED            Shared library: [libz.so.1]

In this case, a program that links with libxml2 and uses dlopen may not link with libdl, and a program that links with libxml2 and uses gzopen may not link with libz. While these programs will work, they are at risk of failure if libxml2 is ever changed to omit the dependency on libdl/libz.

What do I do?

Don't panic! Many packages will have no noticeable problems with the switch. Others may receive an error message telling them to add a DSO to their command line:

For example (courtesy Roland McGrath):

 ==> foo1.c <==
 #include <stdio.h>
 extern int foo ();
 int
 main ()
 {
   printf ("%d\n", foo ());
 }
 ==> foo2.c <==
 extern int foo ();
 int bar () { return foo (); }
 ==> foo3.c <==
 int foo () { return 0; }


magilla 49 % gcc -g -fPIC -c foo1.c foo2.c foo3.c

magilla 50 % gcc -shared -o foo3.so foo3.o

magilla 51 % gcc -shared -o foo2.so foo2.o foo3.so

magilla 52 % gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=

Old result: Works.

New result: /usr/bin/ld: foo1.o: undefined reference to symbol 'foo'

/usr/bin/ld: note: 'foo' is defined in DSO ./foo3.so so try adding it to the linker command line

In the new case, adding ./foo3.so will get rid of the error:

gcc -o foo1 foo1.o foo2.so foo3.so -Wl,--rpath-link=.

Testing eclipse-cdt on F-12

Setup

  1. Use fedora-cvs eclipse-cdt to grab a copy of the CDT from fedora's CVS
  2. In the F-12 folder, cat eclipse-cdt.spec | grep define\ build_id and note the build_id (e.g. v200906161748)
  3. In an Eclipse install, open up the CVS repository and paste :pserver:anonymous@dev.eclipse.org:/cvsroot/tools into the location
  4. Under HEAD, go to org.eclipse.cdt, go into the all folder and right click the packages there. Select Checkout As, then click Next until you get to the final screen. In the Tag box, type the build id. This will start searching for the tag, select it and click Finish


Testing

org.eclipse.cdt.core.tests

  1. suite --> AutomatedIntegrationSuite: 3698 | 0 | 0
  2. parser --> ParserTestSuite: 2259 | 0 | 0
  3. org.eclipse.cdt.core.parser.tests.prefix --> CompletionTestSuite: 5 | 0 | 0
  4. org.eclipse.cdt.core.parser.tests.rewrite.astwriter --> AstWriterTestSuite: 331 | 0 | 0
  5. org.eclipse.cdt.core.parser.tests.rewrite.commenthandler --> CommentHandlerTestSuite 123 | 0 | 0
  6. org.eclipse.cdt.core.parser.tests.scanner --> CommentHandlerTestSuite 261 | 0 | 0
  7. org.eclipse.cdt.internal.index.tests --> All clear
  8. org.eclipse.cdt.internal.pdom.tests --> All clear
  9. model --> org.eclipse.cdt.core.language --> AllLanguageTests 6 | 0 | 0
  10. org.eclipse.cdt.core.model.tests --> AllCoreTests 123 | 0 | 0
  11. org.eclipse.cdt.core.model.tests --> AllLanguageTests 39 | 0 | 0
  12. org.eclipse.cdt.core.settings.models --> AllCProjectDescriptionTests 21 | 0 | 0


The following tests have failures, but they fluctuate

  1. org.eclipse.cdt.core.parser.tests.rewrite.changegenerator --> ChangeGeneratorTestSuite: 43 | 0 | 16
  2. org.eclipse.cdt.core.parser.tests.rewrite.changegenerator.append --> TestSuite: 9 | 0 | 1
  3. org.eclipse.cdt.core.parser.tests.rewrite.changegenerator.insertbefore --> InsertBeforeTestSuite 8 | 0 | 3
  4. org.eclipse.cdt.core.parser.tests.rewrite.changegenerator.remove --> RemoveTestSuite 13 | 0 | 4
  5. org.eclipse.cdt.core.parser.tests.rewrite.changegenerator.replace --> ReplaceTestSuite 13 | 0 | 5

Number of failures varies -- tests pass if you run them directly, but fail otherwise.

org.eclipse.cdt.debug.ui.tests

  1. org.eclipse.cdt.debug.testplugin.util --> ExpectedStringsTests: 4 | 0 | 0
  2. org.eclipse.cdt.debug.core.tests --> AllDebugTests 12 | 0 | 0

org.eclipse.cdt.make.core.tests

  1. org.eclipse.cdt.make.builder.tests --> both tests pass
  2. org.eclipse.cdt.make.core.tests --> AutomatedIntegrationSuite 25 | 0 | 1