On Friday 27 April 2012 05:10:39 Robert Schweikert wrote:

Here is the problem:

simpleValueFromXpdfObj template is declared in src/kernel/cobjectsimple.h. This header file is included in the src/kernel/cobject2string.cc file and thus when this file gets compiled the compiler sees the declaration and knows everything it needs to know to be happy. However, the implementation of the template is in the file src/kernel/cobject2xpdf.cc. The result is that the compiler never sees the use and the implementation of the template at the same time and thus the template is never instantiated. No template instantiation => not entry in the object table. Therefore, when the linker gets around to stich everything together there is only the undefined symbol (location of the call) and no definition.

Once you insert an instantiator into cobject2xpdf.cc the problem is resolved as the compiler will now instantiate the template and the linker can find the definition when stitching things together.

You have a pending SR 115767 which fixes the error.

Thank you very much! Unfortunately this kind of problems is much more difficult to understand than just simply adding "this" in the code :-( In all previous instances when I received a linker error it meant some file or library was not accessible to the linker. I never seen the compiler create a broken module that could not be linked anyhow. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Robert Schweikert (rjschwei@suse.com) [20120427 13:39]:

The joy of templates ;)

And the joy of maintaining a package written in C++ without much knowledge of C++. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Dominique Leuenberger a.k.a DimStar (DimStar@openSUSE.org) [20120427 14:43]:

We always 'advocate' that maintaining the package does not really require 'high programming skills', which I still think is fully true.

Define 'high programming skills' :) But I for instance hadn't started to maintain packages without programming knowledge.

BUT: in this case a very good relationship with upstream and an upstream showing an interest in downstream issues is of course *very* important.

Tell that to someone who was stupid enough to create and maintain the boost packages without a deeper knowledge of C++ and an upstream that doesn't seem to have much interest. All my calls upstream for help with maintaining the boost package have been met with utter silence. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 27 April 2012 16:03:40 Philipp Thomas wrote:

...

The joy of templates ;)

And the joy of maintaining a package written in C++ without much knowledge of C++.

Anyway it seems wrong for me that the compiler brings no error in this case. Should this issue be reported to the gcc upstream? Is not it wrong that the compiler creates a totally unusable object module without any error thrown? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 04/27/2012 11:12 AM, Ilya Chernykh wrote:

On Friday 27 April 2012 16:03:40 Philipp Thomas wrote:

...

...

The joy of templates ;)

And the joy of maintaining a package written in C++ without much knowledge of C++.

Anyway it seems wrong for me that the compiler brings no error in this case. Should this issue be reported to the gcc upstream? Is not it wrong that the compiler creates a totally unusable object module without any error thrown?

No, this is a fundamental feature of C/C++ that allows you to separate the declaration from the implementation. And now for some details, and a longer answer, that you may or may not care about: One of the paradigms of OO programming is to hide your implementation details. Anyone wanting to use your interfaces only has to see the header file at compile time. Then at link time the linker stitches things together. With non templated implementations any link problem then boils down to including the appropriate .o, .a, or .so file on the link line, as you noted previously. However, with templates things get a bit more tricky as the compiler will only emit an implementation when a template is actually instantiated. Template instantiation happens when the compiler sees the use of the template and the template implementation in the same compilation unit, or the compiler is "told" to instantiate a template. To achieve this, implementers have some choices. - Put all template implementations in the header file that gets include by whomever my use the template ~ this approach basically defeats the goal of "hide your implementation" - Put template implementations into separate files (often ending in .T) and include the .T file whenever the .h file is included (in a .cpp, .C, .c++, .cpp .. file) ~ this still achieves the "hide your implementation" goal as users of the template only need to look at the header file to understand the interfaces and while doing so they do not see the implementation ~ but this approach implies that there may be a significant amount of growth for the number of files in a project, many people do not like file proliferation - Put template implementations into a regular file (.C, .cc, .c++, .CC) and compile the file ~ this achieves the "hide your implementation" goal in the way most users think of the organization of C++ code ~ but this implies that in the implementation file one has to have instantiators for the template with all possible types, or linking will fail. This leads to binary bloat as templates that may never be used are instantiated. ~ it is not possible to think of every possible type that might be used to instantiate a template, thus everytime a template instance is needed with a new type one has to add a new instantiator and modify the file that contains the template implementation This last case is the issue you ran into. Yes, one has to have an understanding of how C++ and the compiler work to figure things like this out. But as a packager you do not have to know everything since there's always some one around who can help in one way or another. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org