Using: Open SUSE 11.0 64 bit, KDE 3.5.9 (release 49) and KDevelop 3.5.1

Problem: A singleton was created in subproject A, and so an object file is created in subproject A.

In subproject B, I want to use that object file. We have not been able to find a way to link that object file created in subproject A with subproject B. Also, the subprojects are in different directories.

We created a symbolic link to the ".h" and ".cpp" files in directory A. And the project compiles and links just fine after adding the symbolic link to the header and cpp files in subproject B.

My concern is, that two objects of that singleton will be created. The whole idea of making a singleton is so that there is only one instance at a time. Does someone have a better idea of how to implement this?

"Subproject" is not a C++ concept. So when you say "subproject" I don't know what kind of division you're actually talking about.

Even "singleton" isn't really a C++ concept. So I don't know how you have implemented your singleton. A static member of the class is a typical way to implement a singleton, but not the only way.

I don't know why it should be hard to include object code from a different directory, nor why it should be hard to include source code from a different directory. So you explained a solution (symbolic links to source files) to a problem that you haven't explained.

Most importantly, you haven't explained the run time connection between the two "subprojects". Linked into the same executable? Loaded as two different .so files into the same process? Or what?

With no run time connection, sharing the same instance of the singleton is obviously impossible. With some run time connection, the nature of that run time connection is key to deciding how to share the same instance of the singleton.

Sorry about that, the entire question, I guess is: How do you include object code in another directory? Using KDevelop. We couldn't find anywhere in the subproject settings to do this. (I'm attempting to help someone else here.) I guess the singleton issue isn't really the issue.. but because we only want one instance of a class created and accessed between two different execuatables, we need to figure out how to do this correctly.

I don't know KDevelop well enough to answer the KDevelop part of your question. For that, I think you should edit the title of this thread (edit your first post in the thread and used the Advanced button while editing the post to edit the title).

You are more likely to get the attention of a KDevelop expert if KDevelop is mentioned in the title of your thread.

Regarding the idea of "one instance ... accessed between two different executables", I think you are either confused and/or are still not describing your goal well enough.

Sharing a .o file vs. sharing the source code for that .o file between the build processes of two executables would not make a meaningful difference in the result. The "singleton" would still exist separately in each executable.

I don't have any understanding of the type of sharing you hope to accomplish between those two executables, but if you really do hope to accomplish any type of sharing, I think that requires a mechanism more explicit than a class singleton.

I suspect that what you're fishing for is details of how to put some code into a shared library, which various other executables will refer to and will access at run time. That way, only one copy of that chunk code exists, in the shared library, but multiple programs can make use of it. If two separate programs make use of it at the same time, still only one copy need exist at run time.

It's a while since I've used kdevelop, but the sort of thing you're after would be like this:
and then add a symlink from mylib.so.1.0.1 to mylib.so.1. Read the man page page for ld to learn more about what the -soname and --export-dynamic options to ld actually do. When compiling the object files that you want to include in the library, you will want -fPIC -- see the man page for gcc/g++ about -fPIC and -fpic.

That only applies to the read-only portions of the .so.

The writable portions of the .so would be duplicated.

A singleton class instance in a .so would almost certain be writable (at least from the OS point of view) and would be duplicated, not shared.

Perhaps you could do with a daemon to hold that single instance. Other executables would then access that single instance as a service provided by the daemon. Sockets might provide a way of doing that. No other executable would hold an instance of the class, but they could be informed about its class structure via the declarations in the corresponding header file.

This might do what you need, but I have a feeling that there is likely to be a simpler solution to your actual problem.

johnsfine wrote:
Apologies, I think I misunderstood the original question. If the aim is to have a single instance of an object that multiple processes can access, then perhaps what's wanted is a named shared memory object, see
the Boost Interprocess library.

Thank you all - I'm going to mark this as solved for now and work on this through linking libraries.