ljz%fxgrp.fx.com@ames.arc.nasa.gov (Lloyd Zusman) (10/04/88)
I'm note sure how to solve the following problem involving libraries and global symbols. I'd appreciate any help any of you might be able to provide. I'm trying to build a library called libfoo.a consisting of three object files: common.o, stuff.o, and junk.o. Assume the following routines exist in each file: common.o: common1, common2, common3 stuff.o: stuff1, stuff2, stuff3 junk.o: junk1, junk2, junk3 Now, assume that the common[1-3] routines are called both by the stuff[1-3] routines and the junk[1-3] routines, but they are never to be explicitly called by any user of the libfoo.a library. However, the stuff[1-3] and junk[1-3] routines are callable by users of the library. If in my C source code I declare common1, common2, and common3 to be 'static', then they indeed will not be accessible by the users of libfoo.a, but they also will not be found in the calls made in the stuff[1-3] and junk[1-3] routines that the users *can* access. If, on the other hand, I don't make the common[1-3] routines 'static', they will be found by the linker, but they will cause name clashes with any routines of the same names that the user might have in his or her code that is being linked with libfoo.a. One way to solve this problem is to combine the source code for the three modules into one module, declare the common[1-3] stuff to be 'static', compile the single module into a *.o file, and make that file into a *.a file. But this is impractical for a large application. Is there any way in BSD systems and SYSV systems for me to build my library with the three object files as defined above and still cause the common[1-3] routines to be unknown to the users of the library? I'm not interested in the kinds of condescending replies that often appear on the net to questions like mine ... such as "Who cares about some extra symbols in your library?", or "Why would anyone want to do this in the first place?", or "Read the manual", or something similar. If you don't have anything useful to contribute, please refrain from filling up the net with your insults and your ego trips. Thank you. Try replying by email, but our link is extremely unreliable and you might have to post here. Any useful information I get via email will be summarized here. Thanks in advance, -- Lloyd Zusman Internet: ljz@fx.com Master Byte Software or ljz%fx.com@ames.arc.nasa.gov Los Gatos, California or fxgrp!ljz@ames.arc.nasa.gov "We take things well in hand." uucp: ...!ames!fxgrp!ljz [ our Internet connection is down: use uucp or mail to the entry above it ]
gwyn@smoke.ARPA (Doug Gwyn ) (10/05/88)
In article <LJZ.88Oct3142203%fxgrp.fx.com@ames.arc.nasa.gov> ljz%fxgrp.fx.com@ames.arc.nasa.gov (Lloyd Zusman) writes: >Is there any way in BSD systems and SYSV systems for me to build my >library with the three object files as defined above and still cause >the common[1-3] routines to be unknown to the users of the library? Not unless your linker supports some form of global symbol mapping. The usual solution is to either use names starting with at least one underscore (e.g. mine might be _DAG_whatever), since no sane application will define its own externs with names like that, or to use some common prefix for all the "internal" names in your library (e.g. mine might be DAGwhatever) and warn your customers about this reservation of a portion of name space for your library. Old CDC Fortran compilers used to use names like Q8Qxxx for library functions, and few users had a problem with it.