[genivi-dlt] Bug, or at least inconsistency between DLT, CommonAPI runtimes (C++, D-Bus, ...) and some other GENIVI programs

Helwing, Lutz Lutz_Helwing at mentor.com
Mon Jan 25 04:55:38 EST 2016

Hi Gunnar,

thanks for pointing out this issue.

The main problem is that it was wrongly written in the manual. We have 
fixed this with commit 9e101ff434230a95fb8f4fd33dc48f4970496d1c. The 
patch for this was sent to this list Nov 4th 2015 with subject "DLT user 
manual and package config file are inconsistent with include directory".

Like you said now we have the problem that other users of the library 
have used the wrong convention thus all of them would have to change 
which is not very satisfying.

Personally maybe following your suggestion to allow both conventions 
would be the best way to go?

Please discuss!

Kind regards,

On 23/01/16 01:47, Andersson, Gunnar wrote:
> Here is a "bug" I found years ago in fact but soon after
> the work was kind of abandoned.
> If you remember I did some native compilation of GENIVI programs
> under the small project "GMS" = GENIVI minimal system.
> Local installation again is needed to make somewhat isolated
> build jobs on the Go server for example, and then this bug has
> been noticed again:
> It is a little tricky to decide which project would consider
> changing and so I did not log this in a bug tracker yet but
> bring it here for discussion with the maintainers.
> automotive-dlt.pc [1] includes:
> Cflags: -I${includedir}/dlt
> Many/most/all(?) programs - at least all the CommonAPI runtimes,
> lifecycle components and persistence however use dlt/ as prefix
> for the header includes also, like this:
> #include <dlt/dlt.h>
> That means that if a program does #include <dlt/dlt.h>, then the
> searched path in fact becomes <include-dir>/dlt/dlt/dlt.h which
> of course doesn't exist.
> Here is the twist, if I have understood it correctly -
> this bug is normally not noticed, because in a non-prefix install, the
> headers will be installed in a standard place /usr/include/dlt/dlt.h
> I think most compiles will have /usr/include as a default include
> search directory anyway and therefore <dlt/dlt.h> would be found
> and the compilation succeeds.
> This is however just a lucky coincidence and basically hiding a bug.
> So, when DLT is installed to a non-standard prefix (which is really
> required to do isolated local compilation tests) then this relies
> on the pkg-config and the defined $PREFIX to find the include
> files, and the include-file is not found.
> I would actually recommend and prefer the convention
> #include <dlt/dlt.h> but then the pkg-config must change.
> And looking deeper, I found that the user manual for DLT [2] actually
> says that you should do #include <dlt.h>, which formally means it is
> the CommonAPI tooling, Lifecycle and Persistence that is buggy.
> So what do you guys think, would DLT consider changing the convention
> to <dlt/dlt.h> instead (and fix its pkg-config file), or would you
> claim that all other projects should change?  I'd prefer
> to see it resolved so that it's not necessary to patch this
> to make PREFIX installs work.
> Since there are now two active conventions maybe the safest
> is to add both PREFIX and PREFIX/dlt to the header search path?
> Best Regards
> - Gunnar
> [1] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=automotive-dlt
> .pc.in
> [2] http://git.projects.genivi.org/?p=dlt-daemon.git;a=blob;f=doc/dlt_user_m
> anual.txt
> -- 
> Gunnar Andersson
> Lead Architect, GENIVI Alliance
> Infotainment, Volvo Car Corporation
> _______________________________________________
> genivi-diagnostic-log-and-trace mailing list
> genivi-diagnostic-log-and-trace at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace

More information about the genivi-diagnostic-log-and-trace mailing list