tags:

views:

49

answers:

4

Hi,

I have some c code which provides libfoo.so and libfoo.a along with the header file foo.h. A large number of clients currently use these libraries from /old_location/lib and /old_location/include directories which is where they are disted.

Now I want to move this code to /new_location. Yet I am not in a position to inform the clients about this change. I would want the old clients to continue accessing the libs and headers from the /old_location.

For this, will creating symlinks to the libs/headers to the new locations work?

/old_location/lib/libfoo.so -> /new_location/lib/libnewfoo.so
/old_location/lib/libfoo.a  -> /new_location/lib/libnewfoo.a
/old_location/inlcude/foo.h -> /new_location/inlcude/foo.h

[Note that I need to name the new lib as lib*new*foo and not libfoo due to some constraints. Can this renaming cause any problem? Yet the C code that generates these has not changed.]

It seems to work for the few simple cases I tried. But can there be cases where clients are using the libs and headers in a way which may break as a result of this change. Please let me know what kind of intricacies can be involved in this. Sorry if this seems to be a novice question, I've hardly worked with c before and am a java person.

+2  A: 

You have to differentiate between compile time and run time.

For compile time, clients need to update their Makefile and / or configure logic.

For run time, you simply tell ld.so via ld.so.conf about where to find the .so library (or tell your clients to adjust LD_LIBRARY_PATH, a second best choice). The static library does not matter as its code is already built into the executable.

And yes, by providing symbolic links you can make the move 'disappear' as well and provide all files via the old location.

And all this is pretty testable from your end before roll-out.

Dirk Eddelbuettel
Thanks Dirk for the response. I was concerned in particular about renaming the library from libfoo to libnewfoo. Do you think if that can cause any trouble?
baskin
Yes, that may well break _run time_ if the client uses dynamic linking.
Dirk Eddelbuettel
+1  A: 

I don't see any reason why this would break, this is more a question about symlinks than C. To an unsuspecting user program (one which doesn't have special code to detect symlinks and complain), a symlink is transparent.

If you do experience errors feel free to post them and we'll do our best to advise. However I see nothing off the top of my head that would cause issues.

Sam Post
A: 

The symlinks will work on any operating system and file system that supports symlinks.

Didier Trosset
+1  A: 

The only problem with the symlinks could be if some clients mount the new location with a different path, which is possible in a networked unix type environment. For example, you could have the location as:

/var/stuff/new_location/include/...

and the client could be mounting that as:

/auto/var/stuff/new_location/include/..

In which case a relative symlink might work better, i.e.:

old_location/include/foo.h -> ../new_location/include/foo.h

Another thing to consider is to replace old_location/foo.h with:


/*
 * Please note that this library has moved to a new location...
 */
#include "new_location/include/foo.h"
Andrew Johnson