Description Christian Damus 2011-05-09 14:17:50 EDT

CDT 7.0.2
Reproduced on Mac OS X.  Also observed on Windows 7 64-bit.

The Managed Build System's tool-settings UI lets a naive user attempt to delete a library name (-l) linker option value by pressing the Edit button and deleting the library name.  The result is an empty libname stored in the option in .cproject that cannot be deleted via the UI because the UI subsequently suppresses the empty libname value from the table.

The result of the empty libname is that the internal builder generates a linker command with an extraneous "-l" that causes the link to fail.  The user has a hard time rectifying the problem because the settings UI doesn't show the offending empty libname value; the only recourse is to delete the option element from the .cproject XML.

Steps to reproduce:

1.  Create a managed project building library "foo" using GCC.
     Select the Internal Builder.
2.  Create a managed project building executable "usefoo" that
     is intended to link against library "foo."
3.  In the GCC Linker "Libraries" (-l) setting table, add two names:
     "junk" and "foo."  Add the "foo" project's "Debug" output
     folder to the library path (-L) setting.
4.  Apply the settings.
5.  Return to the Libraries table and edit the "junk" name.  Delete
      the word "junk" (don't delete the table entry).
6.  See that the table now has a blank entry and the "foo" entry.
7.  Apply and close the project properties dialog.
8.  Build library project foo.
9.  Build executable project "usefoo."  See the build fail on an error:

    ld: library not found for -l-lfoo

     This happens because gcc was given "-l -lfoo" options.
10. Open the "usefoo" project properties to try to fix the linker
     settings.  See that you can't because the Libraries table only
     shows one entry "foo".
11.  Open the .cproject file for usefoo.  Find the empty and "foo"
     library name options in the XML.