Rootcint with structs - Problem "undefined symbol"

Hi!
When I try to use rootcint in order to link my GUI with ROOT, rootcint gives a lot of errors like this:

Command:

rootcint -f TCrateGuiDict.cxx -c -p TCrateGui.h TCrateGuilinkdef.h

Errors:

Error: Symbol int32_tam is not defined in current scope  TCrateGui.h:68:
Error: Symbol u_int32_taddr is not defined in current scope  TCrateGui.h:69:
Error: Symbol u_int32_tdata is not defined in current scope  TCrateGui.h:70:
Error: Symbol u_int32_terror is not defined in current scope  TCrateGui.h:71:

The piece of code that is addressed by the error is this:

struct sis1100_vme_req {
    int size;
    int32_t am;
    u_int32_t addr;
    u_int32_t data;
    u_int32_t error;
};

This code is for a driver that is included in the TCrateGui.h.
Simply omitting the inclusion, rootcint runs fine.
The error seems to be related to the symbol names: is “int32_t am” and not “int32_tam”. Any ideas?
Thanks.

Where is the int32_t type defined? You must have an include somewhere.
If this include is not in your current directory, you must specify a -Iincludepath
directive telling rootcint where to find this include.

Rene

[quote=“Stefano”]Hi!
When I try to use rootcint in order to link my GUI with ROOT, rootcint gives a lot of errors like this:

Command:

rootcint -f TCrateGuiDict.cxx -c -p TCrateGui.h TCrateGuilinkdef.h

Errors:

Error: Symbol int32_tam is not defined in current scope  TCrateGui.h:68:
Error: Symbol u_int32_taddr is not defined in current scope  TCrateGui.h:69:
Error: Symbol u_int32_tdata is not defined in current scope  TCrateGui.h:70:
Error: Symbol u_int32_terror is not defined in current scope  TCrateGui.h:71:

The piece of code that is addressed by the error is this:

struct sis1100_vme_req {
    int size;
    int32_t am;
    u_int32_t addr;
    u_int32_t data;
    u_int32_t error;
};

What is int32_t and u_int32_t ? I guess, these are typedefs for int and unsigned int but where do you have these declarations?

I know, there are some typedefs like intN_t or uintN_t in C (not C++). But you need , and I’m not sure if CINT knows about such things

[quote]What is int32_t and u_int32_t ? I guess, these are typedefs for int and unsigned int but where do you have these declarations? [/quote]Strange question? It sounds like your not the original author of the code. (otherwise, do you remember why did you chose those types?). I recommend that your forward this question to the original author. The answer should tell you which header to include (and/or which header CINT is not properly using).

Cheers,
Philippe.

This code is a driver for a VME-Bridge. Obviously it’s not my code or I will know pretty well where the includes are. :slight_smile:
I’m using it in a project for data acquisition… For some reasons it’s necessary an inclusion from TCrateGui.h to the header of the driver. Ommiting this inclusion works well.

I’ve tried using a -I wit no success. This is the error I get at the end:

/usr/include/linux/signal.h:4:20: error: #include nested too deeply

The strange behaviour is that this was not necessary with root 4 (now I’m using root 5.13 on Ubuntu Linux).
For me it’s strange that I have to give an include path to rootcint, but, when compiling the whole program, it’s not necessary to link to this include path…

I’ve noticed also a strange error before the whole list of “undefined symbol” if not using -I

dlopen error: /home/stefano/root513/cint/include/posix.dll: undefined symbol: isDirectory

Why it’s calling posix.dll???

Thanks a lot for the help.

Hi,

I assume that you have the relevant includes if it worked with ROOT v4. The posix error might be a symptom for the real problem. What’s the exact ROOT version you use (5.13.what)? Could you send the headers I need to run rootcint on TCrateGui.h (incl the linkdef) to Axel.Naumann@cern.ch, so I can reproduce the problem?

Cheers, Axel.

Hi Axel,
I’ve sent you the source code.

Thanks for the help.

P.S: I use root 5.13/02 - last development version (the “recommended” one).

Stefano.

[quote]Strange question? It sounds like your not the original author of the code. (otherwise, do you remember why did you chose those types?). I recommend that your forward this question to the original author. The answer should tell you which header to include (and/or which header CINT is not properly using).
[/quote]

Philippe, you quoted part of my message and said “Strange question?”. What is strange in my question? Of course, I’m not the original author of the code, so, I’ve asked him, what is int32_t in his code sample.

[quote]Philippe, you quoted part of my message and said “Strange question?”. What is strange in my question? Of course, I’m not the original author of the code, so, I’ve asked him, what is int32_t in his code sample.[/quote]My point was that this question sholuld be directed to the original author and I assumed that the original author is not reading this forum …

Cheers,
Philippe.

[quote=“pcanal”][quote]Philippe, you quoted part of my message and said “Strange question?”. What is strange in my question? Of course, I’m not the original author of the code, so, I’ve asked him, what is int32_t in his code sample.[/quote]My point was that this question sholuld be directed to the original author and I assumed that the original author is not reading this forum …

Cheers,
Philippe.[/quote]

No. I’m reading this forum. Don’t worry! :smiley: Waiting for a reply from Axel…

Cheers,
Stefano.

Hi,
as Rene pointed out, you need #include <stdint.h> somewhere. As far as I know, that only defines (u)intN_t; at least on my linux box u_intNt isn’t known (i.e. no typedef with leading "u", but only “u”). So you need a few additional typedef uintN_t u_intN_t.

Cheers, Axel.

And what about this problem?

Thanks for the help.
Stefano.

Hi,
I cannot reproduce this problem with the current CVS, so I suppose this bug has been fixed.
Cheers, Axel.