Cannot compile and run on Mac OS X 10.4.7
Hi all, We've tried to compile fr v1.1.2 on os x.4.7 with no luck. We've followed the instructions at doc/MACOSX (using --disable_shared - the mod for the makefile for rlm_sql is already done in this version) but get the following errors during make (this is the tail of the make): /usr/bin/ld: multiple definitions of symbol _CRYPTO_lock /usr/lib/libcrypto.dylib(cryptlib.o) definition of _CRYPTO_lock /usr/local/mysql/lib/libmysqlclient_r.a(libtaocrypt_la-misc.o) definition of _CRYPTO_lock in section (__TEXT,__text) collect2: ld returned 1 exit status rm -f .libs/radiusdS.o make[4]: *** [radiusd] Error 1 make[3]: *** [common] Error 2 make[2]: *** [all] Error 2 make[1]: *** [common] Error 2 make: *** [all] Error 2 And cannot proceed further. --- If you try and compile _without_ --disable_shared, the we get through make with this at the end: /usr/local/src/freeradius-1.1.2/libtool --mode=link gcc -o radwho radwho.lo util.lo log.lo conffile.lo -lresolv -lpthread ../lib/libradius.la gcc -o .libs/radwho radwho.o util.o log.o conffile.o -lresolv -lpthread -L../lib/.libs -lradius creating radwho Making all in raddb... make[2]: Nothing to be done for `all'. Making all in scripts... make[2]: Nothing to be done for `all'. Making all in doc... Making all in examples... /usr/bin/make -C examples all make[4]: Nothing to be done for `all'. Making all in rfc... /usr/bin/make -C rfc all make[4]: Nothing to be done for `all'. The make install has these ominous warning while linking all the libraries for each rlm: ---------------------------------------------------------------------- Making install in rlm_realm... if [ "xrlm_realm" != "x" ]; then \ /usr/local/src/freeradius-1.1.2/libtool --mode=install /usr/local/src/freeradius-1.1.2/install-sh -c -c \ rlm_realm.la /usr/local/lib/rlm_realm.la || exit $?; \ rm -f /usr/local/lib/rlm_realm-1.1.2.la; \ ln -s rlm_realm.la /usr/local/lib/rlm_realm-1.1.2.la || exit $?; \ fi libtool: install: warning: relinking `rlm_realm.la' (cd /usr/local/src/freeradius-1.1.2/src/modules/rlm_realm; /bin/sh /usr/local/src/freeradius-1.1.2/libtool --mode=relink gcc -release 1.1.2 -module -export-dynamic -o rlm_realm.la -rpath /usr/local/lib rlm_realm.lo rlm_realm.c /usr/local/src/freeradius-1.1.2/src/lib/libradius.la -lresolv -lpthread) gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/rlm_realm-1.1.2.so rlm_realm.lo /usr/local/lib/libradius.dylib -lresolv -lpthread -lc -install_name /usr/local/lib/rlm_realm-1.1.2.so /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm-1.1.2.soT /usr/local/lib/rlm_realm-1.1.2.so (cd /usr/local/lib && rm -f rlm_realm.so && ln -s rlm_realm-1.1.2.so rlm_realm.so) /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm.lai /usr/local/lib/rlm_realm.la /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm.a /usr/local/lib/rlm_realm.a ranlib /usr/local/lib/rlm_realm.a chmod 644 /usr/local/lib/rlm_realm.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable during execution See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- AND FOR PERL: Making install in rlm_perl... /usr/local/src/freeradius-1.1.2/install-sh -c -m 755 example.pl /usr/local/etc/raddb if [ "xrlm_perl" != "x" ]; then \ /usr/local/src/freeradius-1.1.2/libtool --mode=install /usr/local/src/freeradius-1.1.2/install-sh -c -c \ rlm_perl.la /usr/local/lib/rlm_perl.la || exit $?; \ rm -f /usr/local/lib/rlm_perl-1.1.2.la; \ ln -s rlm_perl.la /usr/local/lib/rlm_perl-1.1.2.la || exit $?; \ fi libtool: install: warning: relinking `rlm_perl.la' (cd /usr/local/src/freeradius-1.1.2/src/modules/rlm_perl; /bin/sh /usr/local/src/freeradius-1.1.2/libtool --mode=relink gcc -release 1.1.2 -module -export-dynamic -o rlm_perl.la -rpath /usr/local/lib rlm_perl.lo rlm_perl.c /usr/local/src/freeradius-1.1.2/src/lib/libradius.la -L/usr/local/lib /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a -L/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE -lperl -ldl -lm -lc -lresolv -lpthread) *** Warning: This library needs some functionality provided by /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/rlm_perl-1.1.2.so rlm_perl.lo /usr/local/lib/libradius.dylib -L/usr/local/lib -L/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE -lperl -ldl -lm -lc -lresolv -lpthread -lc -install_name /usr/local/lib/rlm_perl-1.1.2.so /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl-1.1.2.soT /usr/local/lib/rlm_perl-1.1.2.so (cd /usr/local/lib && rm -f rlm_perl.so && ln -s rlm_perl-1.1.2.so rlm_perl.so) /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl.lai /usr/local/lib/rlm_perl.la /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl.a /usr/local/lib/rlm_perl.a ranlib /usr/local/lib/rlm_perl.a chmod 644 /usr/local/lib/rlm_perl.a AND RUNNING sudo radiusd -X, the following error results: read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.2.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.2.so Expected in: flat namespace AND QUITS IMMEDIATELY --- We tried googling around and we're happy to hear that freeradius will be a part of 10.5, but we'd like to get it running now... There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :) Thanks in advance for any assistance, Michael Check
On Tue, Aug 22, 2006 at 08:14:30PM -0500, Michael Check said:
Hi all,
If you try and compile _without_ --disable_shared, the we get through make with this at the end:
/usr/local/src/freeradius-1.1.2/libtool --mode=link gcc -o radwho radwho.lo util.lo log.lo conffile.lo -lresolv -lpthread ../lib/libradius.la gcc -o .libs/radwho radwho.o util.o log.o conffile.o -lresolv -lpthread -L../lib/.libs -lradius creating radwho Making all in raddb... make[2]: Nothing to be done for `all'. Making all in scripts... make[2]: Nothing to be done for `all'. Making all in doc... Making all in examples... /usr/bin/make -C examples all make[4]: Nothing to be done for `all'. Making all in rfc... /usr/bin/make -C rfc all make[4]: Nothing to be done for `all'.
That looks fine. raddb, scripts, doc, etcetera aren't compiled, so it looks like it ran to completion.
The make install has these ominous warning while linking all the libraries for each rlm:
---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib
Harmless (mostly). This is only a problem if you don't have that directory in your library search path, but it seems you do.
AND FOR PERL:
*** Warning: This library needs some functionality provided by /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have.
Harmless.
AND RUNNING sudo radiusd -X, the following error results:
read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.2.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.2.so Expected in: flat namespace
Did rlm_exec actually get built and installed? Can you try 1.1.3 (in CVS right now, due Any Day Now) and see if it does better? There was a substantial build system rework involved. Take care, -- -------------------------------------------------------------------------- | Stephen Gran | "You're just the sort of person I | | steve@lobefin.net | imagined marrying, when I was little... | | http://www.lobefin.net/~steve | except, y'know, not green... and | | | without all the patches of fungus." - | | | - Swamp Thing | --------------------------------------------------------------------------
On 8/23/06, Stephen Gran <steve@lobefin.net> wrote:
On Tue, Aug 22, 2006 at 08:14:30PM -0500, Michael Check said:
Hi all,
If you try and compile _without_ --disable_shared, the we get through make with this at the end:
{cut}
Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.2.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.2.so Expected in: flat namespace
Did rlm_exec actually get built and installed?
Can you try 1.1.3 (in CVS right now, due Any Day Now) and see if it does better? There was a substantial build system rework involved.
I had similiar problem with rlm_perl, I had to preload the library: export LD_PRELOAD=/usr/lib/freeradius/rlm_perl.so; freeradius -X regards pshemko
On 8/22/06, Stephen Gran <steve@lobefin.net> wrote:
Did rlm_exec actually get built and installed?
Yes, as far as I can tell, it was in /usr/local/lib
Can you try 1.1.3 (in CVS right now, due Any Day Now) and see if it does better? There was a substantial build system rework involved.
I tried it. ./configure, make, make install with 1.1.3 gets through the process with the same (non) issues as 1.1.2. Running sudo radiusd -X MAI-CHI-MINI:/usr/local/src/freeradius-1.1.3 mcheck$ sudo /usr/local/sbin/radiusd -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/eap.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = "/usr/local" main: localstatedir = "/usr/local/var" main: logdir = "/usr/local/var/log/radius" main: libdir = "/usr/local/lib" main: radacctdir = "/usr/local/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/usr/local/var/log/radius/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid" main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = no proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.3.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.3.so Expected in: flat namespace rlm_exec is built, here is the directory snip from /usr/local/lib lrwxr-xr-x 1 root wheel 11 Aug 23 07:18 rlm_exec-1.1.3.la -> rlm_exec.la -rwxr-xr-x 1 root wheel 21204 Aug 23 07:18 rlm_exec-1.1.3.so -rw-r--r-- 1 root wheel 14488 Aug 23 07:18 rlm_exec.a -rwxr-xr-x 1 root wheel 855 Aug 23 07:18 rlm_exec.la lrwxr-xr-x 1 root wheel 17 Aug 23 07:18 rlm_exec.so -> rlm_exec-1.1.3.so Also tried export LD_PRELOAD=/usr/local/lib/rlm_exec-1.1.3.so sudo radiusd -X And got the same result. Is there any other part of the compile that would be useful to see? Thanks in advance, Michael Check
On Wed, Aug 23, 2006 at 07:40:00AM -0500, Michael Check said:
On 8/22/06, Stephen Gran <steve@lobefin.net> wrote:
Can you try 1.1.3 (in CVS right now, due Any Day Now) and see if it does better? There was a substantial build system rework involved.
I tried it. ./configure, make, make install with 1.1.3 gets through the process with the same (non) issues as 1.1.2.
[snip]
Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.3.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.3.so Expected in: flat namespace
This is a (apparently OS X specific) linker issue, it looks like. debug_flag is declared as an extern int in radiusd.h and included in rlm_exec. ldd shows me that the symbol is present and undefined in the module on linux as well, but the linker magic hooks it all together at run time here. I _think_ that it blows up in rlm_exec because it's the first module that uses a symbol from the radiusd binary (as opposed to a library). I also think this has something to do with the mystery that is OS X's linker namespaces. Beyond that, I'm starting to flounder. I have no Mac machine handy to test these assumptions on (and I'm not even sure how I would test the second one), so I can't really say much more, sorry. I see several references on line about special issues with OS X and dlopen'ed plugins and modules, and I assume this is the problem area. I'm guessing that your way forward is to start hacking on libltdl to make it work with OS X, but that looks, er, painful. If you don't actually need the modules that cause problems, you can comment the references out and see if that gets you by. Good luck, and sorry, but without something to test on, I'm out of ideas. -- -------------------------------------------------------------------------- | Stephen Gran | Better tried by twelve than carried by | | steve@lobefin.net | six. -- Jeff Cooper | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
On 8/23/06, Stephen Gran <steve@lobefin.net> wrote:
I _think_ that it blows up in rlm_exec because it's the first module that uses a symbol from the radiusd binary (as opposed to a library). I also think this has something to do with the mystery that is OS X's linker namespaces. Beyond that, I'm starting to flounder. I have no Mac machine handy to test these assumptions on (and I'm not even sure how I would test the second one), so I can't really say much more, sorry.
In terms of accessing binaries or libs, would it have anything to do with permissions? Is that possible? Does anyone have any suggestions on using, perhaps, a previous version? Or some experience with using a certain version of the OSX developer tools for compiling? I know these questions are a bit obtuse, but I'd like help in even a direction to pursue.
If you don't actually need the modules that cause problems, you can comment the references out and see if that gets you by.
OK, where to do that? In the original make file?
Good luck, and sorry, but without something to test on, I'm out of ideas.
Thanks, I'll need the luck, I guess. Hey, for grins, I compiled and ran version 1.0.5. It makes it through the compile with no problems and when run, I get: unix: radwtmp = "/usr/local/var/log/radius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) radiusd.conf[10] Failed to link to module 'rlm_eap': dlopen(rlm_eap.so, 9): image not found So, similar problem, different module. Am I on to something here? Can someone tell me what I am on to? :) Michael Check
On Thu, Aug 24, 2006 at 09:02:43AM -0500, Michael Check said:
On 8/23/06, Stephen Gran <steve@lobefin.net> wrote:
I _think_ that it blows up in rlm_exec because it's the first module that uses a symbol from the radiusd binary (as opposed to a library). I also think this has something to do with the mystery that is OS X's linker namespaces. Beyond that, I'm starting to flounder. I have no Mac machine handy to test these assumptions on (and I'm not even sure how I would test the second one), so I can't really say much more, sorry.
In terms of accessing binaries or libs, would it have anything to do with permissions? Is that possible?
Does anyone have any suggestions on using, perhaps, a previous version? Or some experience with using a certain version of the OSX developer tools for compiling? I know these questions are a bit obtuse, but I'd like help in even a direction to pursue.
I found someone with OS X 10.4, and we built 1.1.3, 1.1.2, and 1.0.something. They all failed in similar ways to what you are reporting.
If you don't actually need the modules that cause problems, you can comment the references out and see if that gets you by.
OK, where to do that? In the original make file?
In radiusd.conf. They only cause problems at run time.
Good luck, and sorry, but without something to test on, I'm out of ideas.
Thanks, I'll need the luck, I guess.
[snip]
So, similar problem, different module. Am I on to something here? Can someone tell me what I am on to? :)
The problem is that these modules try to use symbols from the radiusd binary, and the OS X linker isn't very clever about dlopen'ed modules or plugins - it has a whole other way of doing it with namespaces and so forth that fails in this instance. This part of the discussion (how linking works) is starting to wander off topic for this mailing list, but I'd be happy to talk about it or give you pointers to links to learn more on your own off list. Take care, -- -------------------------------------------------------------------------- | Stephen Gran | If imprinted foil seal under cap is | | steve@lobefin.net | broken or missing when purchased, do | | http://www.lobefin.net/~steve | not use. | --------------------------------------------------------------------------
I can't say for sure what the problem is, but 1.0.5 is the last one I have been able to get running on Mac OS X. /L Den 24/08/2006 kl. 15.51 skrev Stephen Gran:
On Thu, Aug 24, 2006 at 09:02:43AM -0500, Michael Check said:
On 8/23/06, Stephen Gran <steve@lobefin.net> wrote:
I _think_ that it blows up in rlm_exec because it's the first module that uses a symbol from the radiusd binary (as opposed to a library). I also think this has something to do with the mystery that is OS X's linker namespaces. Beyond that, I'm starting to flounder. I have no Mac machine handy to test these assumptions on (and I'm not even sure how I would test the second one), so I can't really say much more, sorry.
In terms of accessing binaries or libs, would it have anything to do with permissions? Is that possible?
Does anyone have any suggestions on using, perhaps, a previous version? Or some experience with using a certain version of the OSX developer tools for compiling? I know these questions are a bit obtuse, but I'd like help in even a direction to pursue.
I found someone with OS X 10.4, and we built 1.1.3, 1.1.2, and 1.0.something. They all failed in similar ways to what you are reporting.
If you don't actually need the modules that cause problems, you can comment the references out and see if that gets you by.
OK, where to do that? In the original make file?
In radiusd.conf. They only cause problems at run time.
Good luck, and sorry, but without something to test on, I'm out of ideas.
Thanks, I'll need the luck, I guess.
[snip]
So, similar problem, different module. Am I on to something here? Can someone tell me what I am on to? :)
The problem is that these modules try to use symbols from the radiusd binary, and the OS X linker isn't very clever about dlopen'ed modules or plugins - it has a whole other way of doing it with namespaces and so forth that fails in this instance. This part of the discussion (how linking works) is starting to wander off topic for this mailing list, but I'd be happy to talk about it or give you pointers to links to learn more on your own off list.
Take care, --
---------------------------------------------------------------------- ---- | Stephen Gran | If imprinted foil seal under cap is | | steve@lobefin.net | broken or missing when purchased, do | | http://www.lobefin.net/~steve | not use. |
---------------------------------------------------------------------- ---- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
On 8/24/06, Lasse <lassejakobsen@mac.com> wrote:
I can't say for sure what the problem is, but 1.0.5 is the last one I have been able to get running on Mac OS X.
Thanks Lasse, can you tell me a bit about your environment in which it worked? (OSX version, DeveloperTools version, platform, etc.) Did you change anything at compile or run time? Thanks, Michael Check
"Michael Check" <michaelr.check@gmail.com> wrote:
In terms of accessing binaries or libs, would it have anything to do with permissions? Is that possible?
No. And it's annoying as hell, because the modules *can* use the radlog() function, which is in the server core. But they can't seem to use the "debug_flag" variable, which is also in the server core... Maybe the only way to fix this is to turn the "debug_flag" variable into a function. That's crazy, but if it works... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu, Aug 24, 2006 at 01:49:21PM -0400, Alan DeKok said:
"Michael Check" <michaelr.check@gmail.com> wrote:
In terms of accessing binaries or libs, would it have anything to do with permissions? Is that possible?
No. And it's annoying as hell, because the modules *can* use the radlog() function, which is in the server core. But they can't seem to use the "debug_flag" variable, which is also in the server core...
Maybe the only way to fix this is to turn the "debug_flag" variable into a function. That's crazy, but if it works...
That seems like a potential workaround, but it seems to me like the right fix is to make libltdl aware of OS X brain dead behavior, and allow callbacks into the server core from dlopen'ed modules. I don't immediately know how big a project that is, but it seems intuitively better than working around a linker problem with crazy code hacks. Not that I see a better way at the moment, so mark this up as unhelpful. -- -------------------------------------------------------------------------- | Stephen Gran | The 'A' is for content, the 'minus' is | | steve@lobefin.net | for not typing it. Don't ever do this | | http://www.lobefin.net/~steve | to my eyes again. -- Professor Ronald | | | Brady, Philosophy, Ramapo State College | --------------------------------------------------------------------------
Michael Check wrote:
There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Please try version 1.1.3, available on www.freeradius.org. The build tools (autoconf, libtool, libltld) have been upgraded to a recent version. It was reported to work "out of the box" on Mac OS 10.4.7 (ie "./configure" "make" and "make install") http://lists.freeradius.org/pipermail/freeradius-devel/2006-August/010131.ht... -- Nicolas Baradakis
On Wed, Aug 23, 2006 at 12:02:42PM +0200, Nicolas Baradakis said:
Michael Check wrote:
There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Please try version 1.1.3, available on www.freeradius.org. The build tools (autoconf, libtool, libltld) have been upgraded to a recent version.
It was reported to work "out of the box" on Mac OS 10.4.7 (ie "./configure" "make" and "make install")
Is this version now actually released? The download page hasn't been updated, so I wasn't sure if this was still 'in flux' or not. If it's a finalized release, I guess I have some work to do :) -- -------------------------------------------------------------------------- | Stephen Gran | To save a single life is better than to | | steve@lobefin.net | build a seven story pagoda. | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Hi Michael, i was able to build freeradius (at least without any sql support) just yesterday from the latests cvs snapshot without any modifications. maybe you could try this or wait (one day or two?) until the next release (1.1.3). regards markus Zitat von Michael Check <michaelr.check@gmail.com>:
Hi all,
We've tried to compile fr v1.1.2 on os x.4.7 with no luck. We've followed the instructions at doc/MACOSX (using --disable_shared - the mod for the makefile for rlm_sql is already done in this version) but get the following errors during make (this is the tail of the make):
/usr/bin/ld: multiple definitions of symbol _CRYPTO_lock /usr/lib/libcrypto.dylib(cryptlib.o) definition of _CRYPTO_lock /usr/local/mysql/lib/libmysqlclient_r.a(libtaocrypt_la-misc.o) definition of _CRYPTO_lock in section (__TEXT,__text) collect2: ld returned 1 exit status rm -f .libs/radiusdS.o make[4]: *** [radiusd] Error 1 make[3]: *** [common] Error 2 make[2]: *** [all] Error 2 make[1]: *** [common] Error 2 make: *** [all] Error 2
And cannot proceed further.
---
If you try and compile _without_ --disable_shared, the we get through make with this at the end:
/usr/local/src/freeradius-1.1.2/libtool --mode=link gcc -o radwho radwho.lo util.lo log.lo conffile.lo -lresolv -lpthread ../lib/libradius.la gcc -o .libs/radwho radwho.o util.o log.o conffile.o -lresolv -lpthread -L../lib/.libs -lradius creating radwho Making all in raddb... make[2]: Nothing to be done for `all'. Making all in scripts... make[2]: Nothing to be done for `all'. Making all in doc... Making all in examples... /usr/bin/make -C examples all make[4]: Nothing to be done for `all'. Making all in rfc... /usr/bin/make -C rfc all make[4]: Nothing to be done for `all'.
The make install has these ominous warning while linking all the libraries for each rlm:
---------------------------------------------------------------------- Making install in rlm_realm... if [ "xrlm_realm" != "x" ]; then \ /usr/local/src/freeradius-1.1.2/libtool --mode=install /usr/local/src/freeradius-1.1.2/install-sh -c -c \ rlm_realm.la /usr/local/lib/rlm_realm.la || exit $?; \ rm -f /usr/local/lib/rlm_realm-1.1.2.la; \ ln -s rlm_realm.la /usr/local/lib/rlm_realm-1.1.2.la || exit $?; \ fi libtool: install: warning: relinking `rlm_realm.la' (cd /usr/local/src/freeradius-1.1.2/src/modules/rlm_realm; /bin/sh /usr/local/src/freeradius-1.1.2/libtool --mode=relink gcc -release 1.1.2 -module -export-dynamic -o rlm_realm.la -rpath /usr/local/lib rlm_realm.lo rlm_realm.c /usr/local/src/freeradius-1.1.2/src/lib/libradius.la -lresolv -lpthread) gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/rlm_realm-1.1.2.so rlm_realm.lo /usr/local/lib/libradius.dylib -lresolv -lpthread -lc -install_name /usr/local/lib/rlm_realm-1.1.2.so /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm-1.1.2.soT /usr/local/lib/rlm_realm-1.1.2.so (cd /usr/local/lib && rm -f rlm_realm.so && ln -s rlm_realm-1.1.2.so rlm_realm.so) /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm.lai /usr/local/lib/rlm_realm.la /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_realm.a /usr/local/lib/rlm_realm.a ranlib /usr/local/lib/rlm_realm.a chmod 644 /usr/local/lib/rlm_realm.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable during execution
See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ----------------------------------------------------------------------
AND FOR PERL:
Making install in rlm_perl... /usr/local/src/freeradius-1.1.2/install-sh -c -m 755 example.pl /usr/local/etc/raddb if [ "xrlm_perl" != "x" ]; then \ /usr/local/src/freeradius-1.1.2/libtool --mode=install /usr/local/src/freeradius-1.1.2/install-sh -c -c \ rlm_perl.la /usr/local/lib/rlm_perl.la || exit $?; \ rm -f /usr/local/lib/rlm_perl-1.1.2.la; \ ln -s rlm_perl.la /usr/local/lib/rlm_perl-1.1.2.la || exit $?; \ fi libtool: install: warning: relinking `rlm_perl.la' (cd /usr/local/src/freeradius-1.1.2/src/modules/rlm_perl; /bin/sh /usr/local/src/freeradius-1.1.2/libtool --mode=relink gcc -release 1.1.2 -module -export-dynamic -o rlm_perl.la -rpath /usr/local/lib rlm_perl.lo rlm_perl.c /usr/local/src/freeradius-1.1.2/src/lib/libradius.la -L/usr/local/lib
/System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
-L/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE -lperl -ldl -lm -lc -lresolv -lpthread)
*** Warning: This library needs some functionality provided by
/System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a.
*** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/rlm_perl-1.1.2.so rlm_perl.lo /usr/local/lib/libradius.dylib -L/usr/local/lib -L/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE -lperl -ldl -lm -lc -lresolv -lpthread -lc -install_name /usr/local/lib/rlm_perl-1.1.2.so /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl-1.1.2.soT /usr/local/lib/rlm_perl-1.1.2.so (cd /usr/local/lib && rm -f rlm_perl.so && ln -s rlm_perl-1.1.2.so rlm_perl.so) /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl.lai /usr/local/lib/rlm_perl.la /usr/local/src/freeradius-1.1.2/install-sh -c -c .libs/rlm_perl.a /usr/local/lib/rlm_perl.a ranlib /usr/local/lib/rlm_perl.a chmod 644 /usr/local/lib/rlm_perl.a
AND RUNNING sudo radiusd -X, the following error results:
read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1565] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.2.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.2.so Expected in: flat namespace
AND QUITS IMMEDIATELY
---
We tried googling around and we're happy to hear that freeradius will be a part of 10.5, but we'd like to get it running now... There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Thanks in advance for any assistance,
Michael Check - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Markus Krause email: krause@biochem.mpg.de Mogli-Soft: Support for Mac OS X, Webmail/Horde, LDAP, RADIUS by order of the Computing Center of the Max-Planck-Institute of Biochemistry Tel.: 089 - 89 40 85 99 Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de
On 8/22/06, Michael Check <michaelr.check@gmail.com> wrote:
We tried googling around and we're happy to hear that freeradius will be a part of 10.5, but we'd like to get it running now... There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Thanks in advance for any assistance,
This is issue is not really solved, I didn't get it to compile, but I thought those of you that are looking for a solution to run freeRADIUS on OSX should look to the package installer that I found. It is quite recent (version 1.1.0pre0) and runs great. The company has a neat prodcut for managing the scripts that you should look at, too. Here is the url: http://www.carpestellarem.com Thanks, Michael Check
Michael Check wrote:
On 8/22/06, Michael Check <michaelr.check@gmail.com> wrote:
We tried googling around and we're happy to hear that freeradius will be a part of 10.5, but we'd like to get it running now... There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Thanks in advance for any assistance,
This is issue is not really solved, I didn't get it to compile, but I thought those of you that are looking for a solution to run freeRADIUS on OSX should look to the package installer that I found. It is quite recent (version 1.1.0pre0) and runs great.
I don't own an Apple machine, so I'm not able to test it myself. However from what I read on the mailing lists, it should be possible to build version 1.1.3 of FreeRADIUS on Mac OS 10.4.7 with the following commands: $ configure --enable-developer $ make $ su - # make install -- Nicolas Baradakis
Zitat von Nicolas Baradakis <nbk@sitadelle.com>:
Michael Check wrote:
On 8/22/06, Michael Check <michaelr.check@gmail.com> wrote:
We tried googling around and we're happy to hear that freeradius will be a part of 10.5, but we'd like to get it running now... There really is no other docs we've found on getting it compiled (after difficulty like the above) and installed. Certainly nothing recent anyway. Is it true that it _should_ just work? :)
Thanks in advance for any assistance,
This is issue is not really solved, I didn't get it to compile, but I thought those of you that are looking for a solution to run freeRADIUS on OSX should look to the package installer that I found. It is quite recent (version 1.1.0pre0) and runs great.
I don't own an Apple machine, so I'm not able to test it myself. However from what I read on the mailing lists, it should be possible to build version 1.1.3 of FreeRADIUS on Mac OS 10.4.7 with the following commands:
$ configure --enable-developer $ make $ su - # make install
it was actually me who reported sucessful compiling ... i just rechecked it: # downloaded freeradius-1.1.3.tar.gz # ./configure --enable-developer # make # sudo make install and freeradius runs and responds to radtest. another way would be "./configure", then remove the option "-s" in the line "INSTALLSTRIP = -s", then "make", "sudo make install", dont now about additional differences to "--enable-developer" (except from warning flags). but i should point out that i do not use any sql-module (do not have the libraries installed which were required) or unixodbc, and have no libgdbm, so there is no rlm_counter, rlm_ippool. maybe there is your problem? i am using a recent mac os 10.4.7 on an "ancient" g4 powerbook. regards markus
-- Nicolas Baradakis
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Markus Krause email: krause@biochem.mpg.de Mogli-Soft: Support for Mac OS X, Webmail/Horde, LDAP, RADIUS by order of the Computing Center of the Max-Planck-Institute of Biochemistry Tel.: 089 - 89 40 85 99 Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de
participants (7)
-
Alan DeKok -
Lasse -
Markus Krause -
Michael Check -
Nicolas Baradakis -
Pshem Kowalczyk -
Stephen Gran