0

I have created a http library which contains 2 object files (web.o & webssl.o). These two files share some common constants and functions, that must be repeated for each file. Which also means that I need to update both files when changes are made.

I would like to have a webcommon.o file that I can link to the web.o and webssl.o files. It will contain all the common code that both libraries shares.

I created the webcommon.o file with the shared code. I removed the shared code from web.c and webssl.c. When I go to compile web.c and webssl.c with this:

# gcc -Wall -Werror -O3 -c web.c /my/lib/webcommon.o;
gcc: warning: /my/lib/webcommon.o: linker input file unused because linking not done

Through searching, it appears that the -c option ignores the linking of object files.

How do I create a webcommon.o object file that is used with web.o and webssl.o? Right now it looks like my only 2 options are:

  1. Keep the duplicate code in the web.o and webssl.o and update both files when needed.

  2. Make sure I add the webcommon.o file when compiling a program a program with either web.o or webssl.o

Deanie
  • 2,316
  • 2
  • 19
  • 35

3 Answers3

0

The -c tells gcc to compile an object file so you'd want:

gcc -Wall -Werror -O3 -c web.c -o web.o
gcc -Wall -Werror -O3 -c webssl.c -o webssl.o
...

Then you could link them to put your final executable:

gcc web.o webcommon.o -o web
gcc webssl.o webcommon.o -o webssl

When you compile, the symbols defined in webcommon are stubbed out. When you link, your final executable has the functions defined in your common library.

Since I think web and webssl are libraries, you probably want to create a static library:

ar -c web.a web.o webcommon.o
ar -c webssl.a webssl.o webcommon.o

Or just stick it all in one library:

ar -c weblib.a web.o webcommon.o webssl.o
Mike Noeth
  • 63
  • 1
  • 7
0

If it is acceptable for webssl.o to have a link dependency on web.o, then you can just have webssl.o declare the shared variables extern, without defining them. When you link a program with webssl.o and web.o, webssl.o will share those extern variables, and webssl.o will have access to the functions in web.o.

This sort of thing is usually done by creating a header containing prototypes of all the shared functions and extern declarations of all the shared variables. All source files sharing those things include the header, but each shared entity is defined in only one source file. Defining a file-scope variable means providing a declaration with an initializer; defining a function means providing the function body.

If you applied this approach, putting all the definitions in the 'web' module, then web.o could be used on its own, but webssl.o could only be used together with web.o.

Alternatively, if you only use web.o and webssl.o independently of each other, then you could build a static library for each that includes webcommon.o as well. That is,

  • one lib (e.g. libweb.a) containing web.o and webcommon.o, and
  • one lib (e.g. libwebssl.a) containing webssl.o and webcommon.o

You then link the appropriate static library to your programs, instead of linking web.o or webssl.o directly.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
0

You might want to look up ld -r to link object files that can then be relinked.

ld -r -o libweb.o web.o webcommon.o
ld -r -o libwebssl.o webssl.o webcommon.o

You can then link with libweb.o or libwebssl.o as required.

Or you could create actual libraries, either libweb.a and libwebssl.a (archive libraries) or libweb.so and libwebssl.so (shared objects). That is the old fashioned way of providing libraries; it has much going for it. If the entry points for the 'web' and 'webssl' portions are distinctly named, then you could build a single library with all three object files in it, and simply link with that.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278