By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,610 Members | 2,110 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,610 IT Pros & Developers. It's quick & easy.

linker errors because external code is header-files-only

P: n/a
What to do if an external library is header-files-only (but you have
to use it), and you get lots of linker errors?

You will necessarily get linker errors "multiple definition of ..." if
you try to separate interface from implementation in your own code.
The external-library symbols will first be defined in one .o file and
then again in the next one that includes the same implementation-heavy
header.

Is there any way to avoid the linker errors, or do I have to give up
and also put everything in header files myself (resulting in eternal
compilation times etc)?

Thanks!
Markus
Dec 7 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Markus Dehmann wrote:
What to do if an external library is header-files-only (but you have
to use it), and you get lots of linker errors?
What kind of linker errors?
You will necessarily get linker errors "multiple definition of ..." if
you try to separate interface from implementation in your own code.
Huh?
The external-library symbols will first be defined in one .o file and
then again in the next one that includes the same implementation-heavy
header.
Apparently the external library doesn't define their functions 'inline'
if they are all implementations (definitions) and live in headers that
you include in more than one translation unit.
Is there any way to avoid the linker errors, or do I have to give up
and also put everything in header files myself (resulting in eternal
compilation times etc)?
No, don't put everything in headers. You have several options. One,
you could talk to the library creators trying to convince them to fix
the code. Two, you could extract all the declarations from their
headers, create new headers and use those and include *their* headers
in only one of your translation units. Three, you could change their
headers so that every definition is also declared 'inline', which will
not change the inlining, it will only shut the linker up.

Come back and tell us what you found suitable.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Dec 7 '07 #2

P: n/a
On Dec 7, 9:56 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
Markus Dehmann wrote:
What to do if an external library is header-files-only (but you have
to use it), and you get lots of linker errors?

What kind of linker errors?
You will necessarily get linker errors "multiple definition of ..." if
you try to separate interface from implementation in your own code.

Huh?
The external-library symbols will first be defined in one .o file and
then again in the next one that includes the same implementation-heavy
header.

Apparently the external library doesn't define their functions 'inline'
if they are all implementations (definitions) and live in headers that
you include in more than one translation unit.
Is there any way to avoid the linker errors, or do I have to give up
and also put everything in header files myself (resulting in eternal
compilation times etc)?

No, don't put everything in headers. You have several options. One,
you could talk to the library creators trying to convince them to fix
the code. Two, you could extract all the declarations from their
headers, create new headers and use those and include *their* headers
in only one of your translation units. Three, you could change their
headers so that every definition is also declared 'inline', which will
not change the inlining, it will only shut the linker up.

Come back and tell us what you found suitable.
Thanks for the suggestions! I was inexperienced enough not to know
much about the "inline" keyword (and apparently the library writers
were, too). I just added it to the offending functions in the library
code, and the linker is shut up. Maybe I can convince the library
creators to include them in the first place so that things won't break
when I have to upgrade to their next version.

Markus
Dec 7 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.