sifive / freedom-tools

Tools for SiFive's Freedom Platform
217 stars 52 forks source link

build-gdb-py-newlib failed. cannot find -lpython3.7m #65

Closed ken-nakamura closed 3 years ago

ken-nakamura commented 4 years ago

I had the following build error to build gdb.

make -C obj/x86_64-linux-ubuntu14/build/riscv-gnu-gdb-only/build-gdb-py-newlib/ &>obj/x86_64-linux-ubuntu14/build/riscv-gnu-gdb-only/build-gdb-py-newlib//make-build.log Makefile:805: recipe for target 'obj/x86_64-linux-ubuntu14/build/riscv-gnu-gdb-only/build-gdb-py-newlib/stamp' failed make: *** [obj/x86_64-linux-ubuntu14/build/riscv-gnu-gdb-only/build-gdb-py-newlib/stamp] Error 2

I found an error in obj/x86_64-linux-ubuntu14/build/riscv-gnu-gdb-only/build-gdb-py-newlib/gdb/config.log

configure:10319: checking whether to use python configure:10321: result: /home/nakamura/GitHub/freedom-tools/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gdb-9.1.0-2020.07.0-x86_64-linux-ubuntu14/python/bin/python3 configure:10519: checking for python configure:10537: x86_64-linux-gnu-gcc -o conftest -O2 -I/home/nakamura/GitHub/freedom-tools/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gdb-9.1.0-2020.07.0-x86_64-linux-ubuntu14/include -I/home/nakamura/GitHub/freedom-tools/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gdb-9.1.0-2020.07.0-x86_64-linux-ubuntu14/python/include/python3.7m -I/home/nakamura/GitHub/freedom-tools/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gdb-9.1.0-2020.07.0-x86_64-linux-ubuntu14/python/include/python3.7m conftest.c -L/scratch/carsteng/git/py3/install/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -lncurses -lm -ldl >&5 /usr/bin/ld: cannot find -lpython3.7m collect2: error: ld returned 1 exit status

But, I don't have the following directory. /scratch/carsteng/git/py3/install/lib/python3.7/config-3.7m-x86_64-linux-gnu

So, I searched and found the following description in the file, obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gcc-10.1.0-2020.07.0-x86_64-linux-ubuntu14/python/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py.

'LIBPL': '/scratch/carsteng/git/py3/install/lib/python3.7/config-3.7m-x86_64-linux-gnu', 'LIBRARY': 'libpython3.7m.a',

Could you fix it?

cgsfv commented 4 years ago

Yes, I will look into it soon.

Xerosaber commented 3 years ago

Has there been any action on this? I am having the same problem. Or just guidance on a work around would be useful.

cgsfv commented 3 years ago

Sorry - I have been very busy - will look into it within the next couple of days.

jim-wilson commented 3 years ago

Gdb configure uses its own riscv-gdb/gdb/python/python-config.py script which queries LIBPL which points at Carsten's install tree.

gamma17:2248$ pwd
/scratch/jimw/freedom-tools/unpatched/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gcc-10.1.0-2020.07.0-x86_64-linux-ubuntu14/python/bin
gamma17:2249$ ./python3
Python 3.7.7 (default, Jul  6 2020, 09:36:26) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils import sysconfig
>>> sysconfig.get_config_var('LIBPL')
'/scratch/carsteng/git/py3/install/lib/python3.7/config-3.7m-x86_64-linux-gnu'
>>> quit()
gamma17:2250$ 

This works correctly if you use the python3-config in the python install tree, as it has a sed command to replace the original prefix with the installed prefix.

Just an analysis. I don't have a solution.

jim-wilson commented 3 years ago

The easiest work around would appear to be to create the missing directory. I did

    sudo mkdir -p /scratch/carsteng/git/py3/install/lib/python3.7
    cd /scratch/carsteng/git/py3/install/lib/python3.7
    sudo ln -s /home/jimw/SiFive/freedom-tools/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gcc-10.1.0-2020.07.0-x86_64-linux-ubuntu14/python/lib config-3.7m-x86_64-linux-gnu

but now I get this

usr/bin/ld: /scratch/carsteng/git/py3/install/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.a(pylifecycle.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
...

because the native compiler on Ubuntu 18.04 is PIE by default, and can't use the non-pic code in the provided .a file. I would expect this to work on Ubuntu 16.04 though because the native compiler there is no PIE by default. This does require root access to create the directory in /scratch though if you don't have a globally writable /scratch already. I don't happen to have a Ubuntu 16.04 system with root access that I can use for this test though.

As mentioned in issue #70, doing this

    sudo apt-get install python3.7-dev

can work around the problem, as the native compiler can find the native python library if installed. This can't work on Ubuntu 16.04 as it doesn't have this package. This does appear to work on Ubuntu 18.04 as gdb is now building, but I'm not sure if it will run correctly. Better would be to also edit the toplevel Makefile to remove the local python reference, e.g. these two lines

$(UBUNTU64)-rgdb-python      := --with-python="$(abspath $(OBJ_UBUNTU64)/instal\
l/riscv64-unknown-elf-gcc-$(RGT_VERSION)-$(UBUNTU64))/python/bin/python3"
$(UBUNTU64)-rgdb-only-python := --with-python="$(abspath $(OBJ_UBUNTU64)/instal\
l/riscv64-unknown-elf-gdb-$(RGDBP_VERSION)-$(UBUNTU64))/python/bin/python3"

should be deleted. I haven't tried that yet. I'm waiting for my current build to complete.

For Red Hat/Centos, I would suggest grabbing python 3.7 from softwarecollections.org, but unfortunately they only have python-3.6 at this time, so that isn't an option. If the native compiler is not PIE by default then the first workaround of creating the missing dir should work. The second workaround of installing the native python3.7 development package does not appear to be possible.

jim-wilson commented 3 years ago

Sorry, I missed the name when you first reported the bug, or I probably would have looked this earlier. I think you are the Kenichi Nakamura I worked with at Cygnus 20 years ago.

ken-nakamura commented 3 years ago

Yes! Long time no see! Good to see you again! Thank you for your reply. I'll try it.

ken-nakamura commented 3 years ago

It worked on Ubuntu 18.04! Thank you so much!