Freeradius-Users Digest, Vol 118, Issue 30
a.cudbardb at freeradius.org
Tue Feb 17 19:39:45 CET 2015
>>> Is there anything I can do to help get this issue fixed?
>> From previous notes/rants, you need to define -D_XOPEN_SOURCE to match
>> the C standard used.
> Thank, I will look into this. For now I used Alan's suggestion, which seemed to help.
You may run into other issues *ominousness*.
Without _XOPEN_SOURCE, solaris doesn't always expose a POSIX compliant API or work
in a POSIX compliant way.
I'd try and find the right _XOPEN_SOURCE value that allows the server to build and use
that. You'll find the server probably builds with more optional things
>>> Some other problems I ran into but managed to circumvent:
>>> - I have to use gmake, make gives an error on Make.inc, line 33:
>> Unexpected end of line seen
>>> Same issue as http://lists.freeradius.org/pipermail/freeradius-
>>> - I tried using solaris studio's cc, here I get stuck on "checking for
>> talloc.h", even though I include -- with-talloc-include-dir with configure, cc
>> does not know the -isystem it seems
>> Ok. Well, you're welcome to write a patch to check for -isystem to
>> enable/disable it. Or use gcc/clang.
> Just thought I would mentioned it (also helpful for other people trying to compile on solaris in the future),
> I myself have not the knowledge to write good patches, but I am perfectly happy using this workaround, or using gcc.
There's no huge difference between -isystem and -I, -isystem just disables warnings
generated by system headers.
The problem is, it's peppered throughout a bunch of the configure scripts now so it's
annoying to check/fix.
Solaris' compiler is the only mainstream compiler that doesn't support it. Even Intel's
>>> If I try to compile the snippet itself I get a warning that the last return
>> was not reached.
>>> Is my compiler broken, of what could be the issue here?
>> Hm. Fixed that. It's being extra picky.
>>> With GCC I do not have this issue, but I end up in the problem that gcc
>> does not know the -KPIC option,
>>> If I adjust the source to -fPIC, I end up in the same situation above with
>> the udpfromto error.
>> Solaris is a complete pain to build on. I managed to do with with the ldap
>> module disabled.
> It seems with some effort, I managed to build 3.0.6 with rlm_ldap.
> I do compile my own ldap libraries, I do not use the built-in solaris headers/libs.
That'd be why. I was trying to get it to build against the built-in ones. There's
RFC 1823 which defines a common API for all libldap implementations. Unfortunately
rlm_ldap uses some OpenLDAP specific functions.
Due to some recent interactions with the OpenLDAP guys i'm actually quite keen to get
rlm_ldap building against other LDAP libraries.
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Users