Static python build errors..

R

ryanvade

Guest
Hello,

I am attempting to make a portable python for Linux, there is already a version for Windows. So, to do this I have to A.) build static libraries. and B.) install to flash.
This is how I configured...
../configure --prefix=/media/ryanvade/"4 GB Flash"/Portable-Python-3.4 LDFLAGS="-static -static-libgcc" CPPFLAGS="-static"
I then added *static* to Modules/Setup
u
uncommented all the modules I wanted installed and tried to build. I am now getting this:
Code:
/build/Python-3.4.0a2.portable/build/../Modules/socketmodule.c:4588: warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `tan' with pointer equality in `/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libm.a(s_tan.o)' cannot be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
make: *** [python] Error 1
make: *** Waiting for unfinished jobs.
Which appears to be an issue with gcc 4.7. Any ideas?
 


I am not particularly familiar with portable Python, but my only idea is that perhaps this alpha version of Python has a bug. It may be better to try Python3.3.
 
I am not particularly familiar with portable Python, but my only idea is that perhaps this alpha version of Python has a bug. It may be better to try Python3.3.
This is not the first bug I have gotten with 3.4.. Might as well try 3.3.. thanks.
 
Generally, no one should use alpha, beta, or RC software unless they are debugging the software, beta-testers, or have no other choice.
 
If you still have problems compiling Python3, then I would make sure all of the required developer's libraries, these libraries are up-to-date, and the compilation parameters are correct.

I have compiled Python3.3 successfully for the ARM architecture, so I know that Python3.3 will compile correctly. The only differences between our compilations would be the libraries, compiler, and parameters.
 
Generally, no one should use alpha, beta, or RC software unless they are debugging the software, beta-testers, or have no other choice.
This is not important at all, so Beta software sounded fun. I ALWAYS use beta software. Beta kernel, beta Nvidia drivers, beta KDE (when available). Always fastest...
 
This is not important at all, so Beta software sounded fun. I ALWAYS use beta software. Beta kernel, beta Nvidia drivers, beta KDE (when available). Always fastest...

Wow! That is interesting. I only have a few "unstable" applications installed on my system because I am a beta-tester for various applications. To use beta software for the thrill of it is interesting.

I once used software on the Ubuntu backports repository. It was nice to have the latest cutting-edge software. From the backports, I got the newest features before the stable repositories did. I quit using backports after my system crashed, became unusable, and needed to be reinstalled due to some severe bug in the alpha/beta software.

Good luck, beware, and enjoy!
 
Wow! That is interesting. I only have a few "unstable" applications installed on my system because I am a beta-tester for various applications. To use beta software for the thrill of it is interesting.

I once used software on the Ubuntu backports repository. It was nice to have the latest cutting-edge software. From the backports, I got the newest features before the stable repositories did. I quit using backports after my system crashed, became unusable, and needed to be reinstalled due to some severe bug in the alpha/beta software.

Good luck, beware, and enjoy!
Exactly. That is how I have KDE installed. Backported to 4.11.1
 

Staff online


Top