[Click] Error compiling my package in Click for kernel level

Cliff Frey cliff at meraki.com
Mon Feb 6 02:11:27 EST 2012


responses inline

On Sun, Feb 5, 2012 at 10:41 PM, Harkeerat Bedi <hsbedi at memphis.edu> wrote:

> After removing floating point arithmetic, now the following errors remain
> (dmesg output):
>
> [ 4184.551295] click: starting router thread pid 9889 (f3d7f6c0)
> [ 4184.569707] myelementpackage: Unknown symbol __dso_handle
> [ 4184.572406] myelementpackage: Unknown symbol __cxa_atexit
> [ 4197.961612] click: stopping router thread pid 9889
> [ 4197.961637] click module exiting
>
> Can you kindly suggest how I can fix these errors? If they are due to my
> use of static member variables, can we handle these errors without removing
> them?
>

You may need to make your static/global variables be of simple type (or
pointers to classes), and then use a static_initalize() function to
allocate and assign values to those static/global variables.


> Also, in the #define written above, if I cast the values of A and B with
> int64_t, like:
> #define fixedpt_xdiv(A,B) (int32_t)(((int64_t)A << 8) / (int64_t)B)
>
> I get the following additional error:
> [ 4475.103019] myelementpackage: Unknown symbol __divdi3
>
> Can you suggest why casting with int64_t causes such an error?
>

This is causing gcc to assume that libgcc is available, and it is not in
the kernel.  You can use the functions in click/include/click/bigint.hh to
perform 64/32 bit division if you need it.


>
> On a side note, I was interested to see if I could get similar errors if I
> added floating point arithmetic in the sample package provided by Click in
> ...DIR/etc/samplepackage/ directory.
> I added the following code in the initialize() definition in sampleelt.cc:
>
> int
> SamplePackageElement::initialize(ErrorHandler *errh)
> {
>        errh->message("Successfully linked with package!");
>    float temp;
> float temp1 = 121.1211;
> float temp2 = 345234.32423;
>    temp = temp2 / temp1;
>    click_chatter("temp: %d", (int64_t) temp);
>        return 0;
> }
>
> However, the element ran successfully in kernel level, with the following
> output in dmesg:
>
> [14044.407445] click: starting router thread pid 19173 (f4026780)
> [14044.412844] test.click:3: While initializing 'test ::
> SamplePackageElement':
> [14044.412848]   Successfully linked with package!
> [14044.412853] chatter: temp: 2850
> [14046.287880] click: stopping router thread pid 19173
> [14046.287897] click module exiting
>
> Can you kindly suggest why we did not observe any errors for using floating
> point arithmetic in this case?
>

That code is completely inlined/executed at compile time.  Try marking one
of the variables as "volatile" or make one of them depend on a runtime
quantity, and that code will fail to load as well.

Cliff


More information about the click mailing list