Community
Participate
Working Groups
I have a managed make cpp project project links a lib in another project, which is done by adding it in project properties/GCC C++ linker/libraries. Build is successful, but the libraries container in C/C++ project view has a question mark on the lib, and there is a warning message in Problems view: "Invalid project path Library not found..." Plus, no properties option in context menu for the libs under libraries folder.
Hi Mikhail, I CCed you after I saw your reply to post "Managed Build Bug" this morning on cdt-dev-list. Maybe this is the same issue? Thx... James
Switched to cdt-core and add Alain to CC list.
Hi James, Sorry for not responding sooner. The reason of the problem you are seeing is that the MBS code that calculates the list of libarary path entries defined in MBS option, currently assumes that the LIBRARIES options contain either relative or absolute library paths, which is untrue. I suppose we might currently disable that code and make MBS calculate only MACRO and INCLUDE path entries. Thanks, Mikhail
*** Bug 102394 has been marked as a duplicate of this bug. ***
I'm confused about what the libraries container in the C/C++ View is supposed to contain. MBS has "includes" implemented correctly (I think), but looking at "libraries" now, I'm not even sure about what it is supposed to contain. /** * Return the library references for this project. * * @return [] ILibraryReference */ ILibraryReference[] getLibraryReferences() throws CModelException; What exactly are "library references"?. Most (all?) C/C++ compilers allow you to specify both library names and library paths upon which to search for the named libraries. Are "library references" the library names, the library paths (which would make them similar to the "includes" entries), full library paths resolved using the names and paths, or something else? As Mikhail suggests, unless the answer is easy to implement, we will probably have to remove this support from the MBS for 3.0.
Then we'd better tag this against 3.0 to make sure it gets fixed.
(In reply to comment #5) > I'm confused about what the libraries container in the C/C++ View is supposed > to contain. MBS has "includes" implemented correctly (I think), but looking > at "libraries" now, I'm not even sure about what it is supposed to contain. > > /** > * Return the library references for this project. > * > * @return [] ILibraryReference > */ > ILibraryReference[] getLibraryReferences() throws CModelException; > > What exactly are "library references"?. Most (all?) C/C++ compilers allow you > to specify both library names and library paths upon which to search for the > named libraries. > > Are "library references" the library names, the library paths (which would make > them similar to the "includes" entries), full library paths resolved using the > names and paths, or something else? > > As Mikhail suggests, unless the answer is easy to implement, we will probably > have to remove this support from the MBS for 3.0. > It is library that are referenced by the project. And usually those libraries are outside of the workspace, it provides navigation capabilities and will help debugging, for example when using the ELF parser the libraries can be open and breakpoints can be added. So if a libary is referencing/Linking with libsocket.so/.a You can return an IPathEntry for the library path /usr/local/lib/libsocket.so It will then appear in a "virtually" folder under the project. You can see this in action in Standard make project, In the Propety page of the standard project, the Make Project You can add library references
Thanks, Alain, for the description. I think we'll need to disable this support for CDT 3.0. The problem is that the MBS has a special option-type that identifies the option specifying the libraries, but does not have a special option-type to identify the additional library paths. Without the additional paths, MBS will not be able to find all of the libraries. I believe it is too late in 3.0 to add a new option-type.
I have disabled the CDT_LIBRARY calculation from the managed build options for now. The issue should be gone now. I'm changing the target milestone to the future and correcting the bug summary in order to implement the CDT_LIBRARY calculation for MBS in the future
Here are my thoughts regarding resolving the issue: There are several ways that could be used for obtaining libraries used wile linking: 1. The scanner info provider mechanism could be used. 2. Libraries could be calculated by MBS based on the library paths and library names specified in MBS options Tool-integrator should be able to implement any or both of these approaches. Using the scanner info mechanism: The scanner info approach can be already implemented using the ScannerConfigurationDiscoveryProfile. E.g. for the gnu tool-chain the following scanner info provider could be defined along with the already existing provider that obtains includes and macros: <scannerInfoProvider providerId="specsFile"> <run arguments="… -Wl,--verbose ${plugin_state_location}/${specs_file}" command="gcc" ... /> ... </scannerInfoProvider> Note: in the above example the “--verbose” argument is passed to the linker, so the linker will report the process of searching libraries. Library calculation by MBS: MBS will need the following info in order to calculate the full library file path based upon the library name: 1.A set of directories where a library is to be searched. 2.A set of file name patterns that would tell MBS how to calculate the file name from the library name, e.g. the “lib=.so” pattern could mean that for the “foo” library name the “libfoo.so” file should be searched. Based on this information MBS would search for the library files in the lib directories. To provide MBS with a set of lib directories a new option type “libpaths” should be defined that would represent library paths. To allow the file name from a lib name calculation a tool-integrator might be allowed to provide a set of patterns that will tell MBS what file names should be searched for the given lib name, e.g. the “lib=.so” pattern would mean that for the “foo” library name the “libfoo.so” file should be searched. The main difficulty here is that the set of file names to be searched might depend on the value of some other options, e.g. in case of gcc (ld) on linux, if a foo library name is specified linker will search for the libfoo.a if the –static option is specified and for the libfoo.a and libfoo.so otherwise. To overcome this we might allow tool-integrators specify several patterns along with conditions when those patterns should be taken into account. So the “libs” option could be allowed to have several “filePattern” child elements that would have the “patterns” attribute containing a comma-separated list of file name patterns. E.g. the “lib=.so” pattern would mean that for the “foo” library name the “libfoo.so” file should be searched. The "filePattern" element would be also allowed to have an “enablement” child element that could contain Boolean expressions to specify when the pattern should be taken into account. The Boolean expression could be in the form of Boolean enablement expressions used in action filters in UI, e.g. it could contain “and”, “or”, “not” and “optionState” elements. E.g. for the gnu tool-chain the –l option definition could be extended as follows: For linux: <option name="%Option.Posix.Libs" category="gnu.c.link.category.libs" command="-l" id="gnu.c.link.option.libs" browseType="none" valueType="libs"> <filePattern patterns=”lib=.so”> <enablement> <optionState optId=”gnu.c.link.option.noshared” optVal=”false”/> </enablement> </filePattern> <filePattern patterns=”lib=.a”/> </option> For cygwin: <option name="%Option.Posix.Libs" category="gnu.c.link.category.libs" command="-l" id="gnu.c.link.option.libs.cygwin" superClass="gnu.c.link.option.libs" browseType="none" valueType="libs"> <filePattern patterns=”lib=.dll.a,=.dll.a,cyg=.dll,lib=.dll,=.dll”> <enablement> <optionState optId=”gnu.c.link.option.noshared” optVal=”false”/> </enablement> </filePattern> <filePattern patterns=”lib=.a,=.lib”/> </option> Comments/suggestions are welcome...
Adding Leo and Chris to the CC list
Leo, Chris, please see my previous comment with proposal...
This is getting quite complex and still misses some cases: - Cygwin has a -dll-search-prefix option that defaults to "cyg" but can be changed. - With the MS linker, libraries are typically specified on the command line just as object files are. There is no "name prefixing" and typically no switch that identifies them. Does ld also allow library names to be specified without using the -l switch? - With MS, there is a /defaultlib and a /nodefaultlib switch that overrides it. Determining the exact set of libraries that ld/link used seems like it is going to be quite complicated. Are we going to be happy with a 90% solution? Does the location of libraries used become part of the linker output information? That is, could a binary parser be used to get it?
Hi Leo, You are right that this is a complex problem > This is getting quite complex and still misses some cases: I think that issues 1 and 3 you mentioned could be easily resolved. See my comments embedded below.. > > - Cygwin has a -dll-search-prefix option that defaults to "cyg" but can be > changed. This issue could be resolved by allowing to use the build macros in the file patterns. In this case the pattern for cygwin gcc could be defined e.g. as “${cyg}=.dll”, where the ${cyg} macro will be provided with the gnu tool-chain definition and its value will depend upon the -dll-search-prefix value > > - With the MS linker, libraries are typically specified on the command line > just as object files are. There is no "name prefixing" and typically no switch > that identifies them. Does ld also allow library names to be specified without > using the -l switch? > > - With MS, there is a /defaultlib and a /nodefaultlib switch that overrides it. This issue could be overcome using Boolean expressions, e.g. here is the file pattern that could be used in the /defaultlib option definition: <filePattern patterns=”=”> <enablement> <not> <optionState optId=”nodefaultlib.option.id” optVal=”=”/> </not> </enablement> </filePattern> <filePattern patterns=”lib=.a”/> Note: in the above example the pattern contains the enablement expression that specifies that the /nodefaultlib option value should be checked and /nodefaultlib should not contain the library specified for the /defaultlib option.. > > Determining the exact set of libraries that ld/link used seems like it is going > to be quite complicated. Are we going to be happy with a 90% solution? I agree that the solution is a bit complicated and probably will not cover the 100% of cases. So if you think it is not worth implementing currently, we could use only the scanner info provider mechanism for now. This approach will provide the complete and precise set of libraries used by the linker. What do you think? >Does the location of libraries used become part of the linker output information? > That is, could a binary parser be used to get it? >
Moving back to inbox
The current state of the world on this... I'm interested in reconciling the core ICSettingsEntry (managed build extensions) with managed build's notion of the set of Library Files. Managedbuilder.core IOption has 3 types of Library entity: IOption#LIBRARIES - 'libs' type currently used for -l in the GNU toolchain IOption#LIBRARY_PATHS - 'libPaths' currently used for -L library search paths in the GNU toolchain IOption#LIBRARY_FILES - 'libFiles' currently unused by any built-in toolchains. In CDT.core we have: Build system settings: ICSettingEntry#LIBRARY_PATH ICSettingEntry#LIBRARY_FILE Core model: IPathEntry#CDT_LIBRARY Currently the cdt.core.model PathEntry isn't filled with library files from the build system's ICSettingEntry, this is essentially what this bug is about, which I haven't changed. For the purposes of fixing bug 229085 -- which requests library names to be automatically propagated between referenced projects -- I've contributed the IOption#LIBRARIES option type back into the ICSettingEntry model. As is done currently for the LIBRARY_PATHS option type. Fundamentally there are 3 library types in managedbuild.core, 2 in the cdt.core.settings interface to the build system, and 1 in cdt.core model. In the build system LIBRARIES and LIBRARY_FILES are similar. LIBRARIES is a list of libnames, LIBRARY_FILES is a list of paths to library files (currently unused in the gnu integration). It doesn't make a huge amount of sense for a toolchain to have / support both of these types of entry. As a result I've mapped the LIBRARIES type to LIBRARY_FILE in cdt.core. As they're the raw library name, they're 'unresolved'. If a toolchain has both LIBRARIES and LIBRARY_FILE types then a warning will be emitted; we can fall back to the previous behaviour of ignoring LIBRARIES. The upside of this is that, using the core API, ISVs can now contribute libraries as well as library paths to be picked up and used by managedbuild. Referenced project libraries can also be automatically propagated into the derived project, and, with the ability to re-order project references (in HEAD), means it's much easier to manage many interdependent projects.
These warnings are back when using the new project references improvements. As we now export IOption#LIBRARIES back to cdt.core (for propagation to referencing projects), cdt.core can't resolve the libs as there isn't enough information. e.g. -L/some/project/path -lfoo needs to become /some/project/path/libfoo.{a,so} Mikhail's proposed a solution that looks quite heavy, for the moment I'd rather not contribute these paths back to the CModel as has been the case since 2005.
*** Bug 307052 has been marked as a duplicate of this bug. ***
