Not yet. I have a daily Mottainai job that compiles freeradius. I will say you something Monday after some tests with a use case that we have in a project. On Sat, 2019-12-07 at 14:36 +0000, Jorge Pereira wrote:
Hi Geaaru,
Good to hear that. btw, did you test the "import <module>" also?
Get Outlook for Android
On Sat, Dec 7, 2019 at 10:29 AM -0300, "Geaaru" <geaaru@gmail.com> wrote:
Hi Jorge, I confirm that with your patch compilation is OK. I applied your patch to 3.0.20 ebuild (with libressl patch) so if tests will be ok I will do a pr to Gentoo portage. https://github.com/geaaru/geaaru_overlay/commit/d8835f1a7d43378560ff0819bbb9... FYI: Gentoo will drop support to rlm_python (2.7) for the releases
=3.0.20. Thanks On Sat, 2019-12-07 at 00:32 +0100, Geaaru wrote: Ah ok. Thanks for clarifying that. Of course. I will test your patch Monday or Tuesday and I will report back to you.
Have a nice weekend. On Fri, Dec 6, 2019, 23:06 Jorge Pereira <jpereira@freeradius.org
wrote: Hi Geaaru, So, the problem about the “import <module>” was fixed as can be seen in https://github.com/FreeRADIUS/freeradius-server/pull/3184 (Not merged, yet). Basically, the current code is using PySys_SetPath() to set the Python path. but, only now we figured out that such function reset the entire Python path. the result is not permitting to import any module installed or provided by the Python instance.
Conclusion: The fix is keeping the default Python path (of course) and then appending the extra paths configured in through the option “python_path” in ${raddb_path}/mods- available/python Please, if you don’t mind. Perform again your tests using the branch https://github.com/jpereira/freeradius-server/tree/v3/python-3180 (Already with the ‘import <module>’ and build fixes) We appreciate any feedback.— Jorge Pereirajpereira@networkradius.com
On 6 Dec 2019, at 18:08, Geaaru <geaaru@gmail.com> wrote:
Hi, yeah your patches follow my idea. Yours seems better on detect if python3-config is present.
But in general what you have did instead of me is this (between other):
s/-Xlinker -export-dynamic//g
you disable export-dynamic that is used FWIK to permit 'import <module>' inside the code. It's this from my side that generate my error.
Have you ever see if there a way to maintains this ldflags and fix linking phase? On Fri, Dec 6, 2019, 21:04 Jorge Pereira < jpereira@freeradius.org> wrote:
Hi Geaaru,
Actually, It’s not quite simple to have a generic configure.ac able to detect the Python embedded CFLAGS/LDFLAGS/... options using only the interpreter.
So, as we already have in the v4 (master branch).
We intend to use the "pythonXX-config" utility to get the "CFLAGS/LDFLAGS/PATHs/..." properly as suggested by the Python embedded documentation https://docs.python.org/3/extending/embedding.html?highlight=python3%20confi...
Therefore, we appreciate if you could use/test the patch as suggested by Alan.
----
Jorge Pereira
jpereira@freeradius.org
> On 6 Dec 2019, at 16:52, Alan DeKok < aland@deployingradius.com> wrote:
>
> On Dec 6, 2019, at 2:41 PM, Geaaru <geaaru@gmail.com> wrote:
>> i'm trying to integrate Python3.6 support in Gentoo/Sabayon distro and
>> I will soon push a pr that fix this support on configure.ac but I see
>> that also with python2.7 before my changes export- dynamic link option
>> was disabled.
>>
>> Here my patch:
>>
>> https://github.com/geaaru/freeradius-server/commit/1862610feab8b3e165ca0b57d...
>>
>> Now I also fixed this but I have this issue:
>> ...
>> gnu/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): relocation
>> R_X86_64_PC32 against undefined hidden symbol `__init_array_start' can
>> not be used when making a shared object
>
> That's likely because of build arguments...
>
>> Could be related to gcc version? Anyone has alraedy see this error?
>
> Jorge has a patch at:
>
> https://github.com/FreeRADIUS/freeradius-server/pull/3183
>
> That may help.
>
> Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html