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 Pereira jpereira@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