multiple definition of __getreent

Chris Johns chrisj at
Mon Jun 22 00:07:08 UTC 2015

On 22/06/2015 3:24 am, Sujay Raj wrote:
> @Chris , I used  'target_link_libraries' in mk_bin/CMakeLists.txt to
> link libc.a and libbsd.a to the monkey-bin target

I think touching anything in Cmake with the hack around we have using is
only going to cause issues. We are currently working around cmake with
environment variables.

I think you have resolved the issue reading further down. Something to
remember for the future is a cmake trace can be obtained using 'make
VERBOSE=1' (oh the joys of cmake ... smile, smile lots, say nothing)

> @Joel, removing -O0 doesn't work too.
> I needed libc for three function , initgroups, timegm, and sendfile.

We do not have sendfile in a library:

$ arm-rtems4.11-nm /opt/work/rtems/4.11/arm-rtems4.11/lib/*.a | grep
$ arm-rtems4.11-nm
| grep sendfile
$ arm-rtems4.11-nm
| grep sendfile

> Today I figured that monkey can function without 'initgroups' , if it is
> given all privileges, which I think will be the case when it runs on
> rtems (I tested on linux and when run from root, it can work without
> initgroups) . 

Yes lets not get too concerned about perms yet.

> And I wrote a my_timegm function emulating what timegm
> does. So these two functions aren't needed anymore. (both were tested
> and working on linux)
> The problem comes with sendfile.
> So, just to get things working, I also wrote a make shift version of
> sendfile using read/write (which is working on linux, but is
> theoretically slow).

Excellent solution and performance is not a concern at this point in time.

If there is a sendfile in FreeBSD we could add it to libbsd.

> Doing the above removed the requirement of linking libc.a totally.

I suspect a host vs RTEMS interaction.

> So yeah, we now have a working version of monkey on rtems using libbsd,
> which is ready to be tested on qemu. Though, this is not the ideal
> circumstances that we would have hoped for, and I certainly would want
> monkey to be using the default sendfile from the library.

Sorry to disagree but I actual think this is pretty good so well done. :)

Lets get the patches sorted and up stream then the fun and games with
cmake can start. The method of cross-compiling with cmake we are
currently using is a hack.


More information about the devel mailing list