How to build a library with dependent library?

[pvanoppen2]

I have a Linux project set up that builds a static library: libcompat.a which holds (among others) setproctitle.o A second Linux library (libcommon-daemon-lib) should include some new objects files (log.o and ctl.o) and the complete content of the generated libcompat.a

Using ar it would look something like : ar cr .libs/libcommon-daemon-lib.a log.o ctl.o .libs/libcompat.a/setproctitle.o ...

In Visual Studio I could create libcommon-daemon-lib.a just by listing out the source files, but that means that setproctitle is compiled twice, which is not efficient. When I add a reference in libcommon-daemon-lib to libcompat, the dependent lib is build first (great) but is there an elegant way to get the content into the new library?

If this can only be done with a Remote Post Build process step, how do I reference the remote output directory of the libcompat project? For the current project that would be $(RemoteOutDir)$(TargetName), but is there a way to access the properties of another project in the same solution, something like: $(libcompat.RemoteOutDir)$(libcompat.TargetName) ?

Using Visual Studio version 15.9.5, compiling for Ubuntu 16.04LTS x64

[pvanoppen2]

It appears that references to Linux targets have a problem. When I add a reference to a library it claims a Microsoft.VisualStudio.ProjectSystem.References.UnresolvedBuildDependencyProjectReference" reference could not be resolved. , even though the library builds successful on the remote target.

[pvanoppen2]

This issue was presumable fixed some time ago, but appears in my 15.9.5 Version of Visual Studio. https://developercommunity.visualstudio.com/content/problem/196761/linux-c-project-doesnt-allow-to-specify-path-to-a.html

[yuehuang010]

I am not able to repro the issue. Could you share your sample?

[pvanoppen2]

I created a libA, that generates a static library (liblibA.a), leaving most settings as default. Next a sandbox project (also with most settings left as default) with a simple main() is able to include (and use) the method declared in the references libA. However the liblldpctl project, which tries to include the same libA, indicates a warning sign at the library
Reference.

It must be some project setting of liblldpctl that must prevent the inclusion of libA.

[pvanoppen2]

To be more specific, the reason that you could not reproduce the issue was that you included the library into an application... The question however was, how to include a (static) library into a library. So in stead of your console application, create a libConsole project and set the Configuration Type to Static library (.a) . I did that for libSandbox (see picture) and you can see the warning sign when referencing LibA

The expected behavior is that the object files created for the primary library (libA) are included in the secondary library (libSandbox).

[yuehuang010]

Thanks, I found the issue for the "warning" marker. Are you still having problems with the build?

[pvanoppen2]

Well, the work around is, to duplicate the source files of the nested library, which is not as elegant. Are nested libraries supposed to work, or is it a feature that just is not supported? In other words, I could not create a Sandbox Application that includes/ references libSandbox.

If it is a bug (then it should be possible to create a static library with a reference to another library), could you post a link to the issue so I can see when it is addressed. If it is a a non supported feature we can close this topic.

[itodirel]

Libraries consume the %(Link) item group, and archives consume the %(Lib) item group, in theory you could consume the .a directly without having to rebuild the library, @yuehuang010 would that work?

[artem-korolev]

Hi, here is example - https://github.com/artem-korolev/visual-studio-issues.git

There are 4 projects. Two under "Main", and two under "Tests"

"test-server" and "test-client" from Tests have reference to "ApiCppStatic" project. If you double click "ApiCppStatic" from "References" tree node, then it opens Object Browser.

"Services" project from Main section also references "ApiCppStatic". But if you double click on this reference, then it shows "The "Microsoft.VisualStudio.ProjectSystem.References.UnresolvedBuildDependencyProjectReference" reference could not be resolved." message. In properties window it is also same message instead of Full Path

Difference here is that "Services" is static library project that references to another static library project. And UI is broken for this type of reference. "test-server" and "test-client" are console applications that reference static library. And UI here works good without issues.

Well. I want to notice one more thing. project I post here is already modified and don't have real code already. But there was a code, which was working. Reference to static library was broken in UI interface, but build was successful and executable was fully working using this static library.

So I want to say, that this is only UI interface issue. The actual build is fully working. I hope it will be fixed anyways, cause such issues confuse a lot

I use WIndows. But It seems to me the same issue. Hopefully it will be fixed in both version at once :)

[artem-korolev]

Well. I found solution for my particular problem

[itodirel]

Tracking using #363

We have retired this issue list, here on Github. We now adopted and are using the Developer Community (https://developercommunity.visualstudio.com/spaces/62/index.html), for Cross Plat and Linux experiences (and C++ generally), which we are actively monitoring. Please use the Developer Community, to report issues or suggestions for bugs or new experiences. Further discussions on this thread here on Github might be unmonitored. If there is further comments or context to this current issue, please create a new issue on the Developer Community, and provide the context there. For any existing issues, which we can or able to reproduce, or for anything that is actionable to us and understood, we will provide an update right here in this thread. Additionally, for new suggestions or new issues, which at this time are in our roadmap, or for which we believe and have evidence that broadly and/or significantly benefit everyone, we will open a suggestion ticket, and link it here. For anything else, we recommend to please open a ticket on the Developer Community. That isn't because we will not look at the problem, or not investigate it otherwise, but simply because we need additional information. And for features, we are tracking them on the Developer Community.