[SOLVED] linking objects in separate directories using KDevelop
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
linking objects in separate directories using KDevelop
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?
Last edited by mbsmo; 10-05-2010 at 07:55 AM.
Reason: Title does not describe problem correctly
"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.
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.
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.
Distribution: Linux From Scratch. 64 bit. Kernel 5.8.3. Fluxbox.
Posts: 53
Rep:
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.