Not sure if this is the correct place for this kind of question. If not, please point me in the right direction.
I'm using OSX 10.5.8 on a white 13" macbook with Xcode 3.1.4. When installing py27-bottleneck through macports, I get the following error
---> Building py27-bottleneck
running build
running build_py
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
package init file 'bottleneck/tests/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/func/__init__.py' not found (or not a regular file)
package init file 'bottleneck/src/move/__init__.py' not found (or not a regular file)
running build_ext
building 'func' extension
/usr/bin/gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c bottleneck/src/func/func.c -o build/temp.macosx-10.5-i386-2.7/bottleneck/src/func/func.o
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1760,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17,
from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from bottleneck/src/func/func.c:314:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/__ufunc_api.h:242: warning: ?_import_umath? defined but not used
cc1(53864) malloc: *** mmap(size=298745856) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
cc1: out of memory allocating 298742336 bytes after a total of 0 bytes
error: command '/usr/bin/gcc-4.2' failed with exit status 1
Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/work/Bottleneck-0.8.0" && /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 setup.py --no-user-cfg build
Exit code: 1
Error: org.macports.build for port py27-bottleneck returned: command execution failed
Warning: targets not executed for py27-bottleneck: org.macports.activate org.macports.build org.macports.destroot org.macports.install
Please see the log file for port py27-bottleneck for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-bottleneck/py27-bottleneck/main.log
Error: Problem while installing py27-bottleneck
I don't really know what the problem is and why this had happened, but what I noticed was that macports is still using an old compiler.
So does anybody know how I can fix this problem?
Also, why is macports still using gcc-4.2, while I have all my symlinks pointing at /opt/local/bin/gcc-mp-4.8. I remember having this problem earlier with installing some other python packages (or maybe it was this one, I don't remember), so I forced macports to use the newer compiler by changing the makefile and it worked temporarily. Until I started upgrading my outdated ports. Obviously now macports encountered linking errors and just reinstalled the all those packages (this is where I am now). So why does macports not just use the newer compiler? Or how can I make him do this? (maybe I shouldn't?)
Any help is appreciated. Thanks.
On 10.5.8 with Xcode 3.1.4 MacPorts uses the following compilers (in-order, unless blacklisted by ports because known to break):
GCC 4.2 from /usr/bin
A MacPorts build of the same compiler (with a few minor bugfixes)
GCC 4.0 from /usr/bin
Clang 3.3 from MacPorts
It seems this port should be blacklisting GCC 4.2 (and probably 2. and 3., too). You could file that as a bug, but to be honest, support for 10.5 is only given on a best-effort basis because most maintainers can't test on this platform anymore, so that's probably not getting you anywhere unless you provide a patch with your report.
You could override the compiler from command line like you did before. To stop rev-upgrade from immediately starting rebuilds, you can set revupgrade_mode report in your macports.conf. I'd have to see the output of port -dy rev-upgrade when it encounters broken ports to know why it produces broken binaries.
It has already been mentioned that the select mechanism doesn't affect which compilers MacPorts chooses for its ports (because depending on what's selected by the user would add another variable that might make builds unreproducible, which is something we're trying to avoid). MacPorts' default compilers can be changed, but doing so is completely unsupported and deliberately undocumented. That being said, if you still want to attempt this, https://apple.stackexchange.com/questions/118550/define-local-keyword-globally-in-a-macports-config/122997#122997 has some info on how to do that.
Related
I am trying to compile a C code on Oracle Linux 7.2 which is hosted as VM on windows 10.
Name of file run: configure
Name of log file: confg.log
Error where I am stuck
gcc: error: unrecognized command line option '-V'
As per my understanding of the code structure so far, there is a file named configure which is having compilation related commands and this file generates Makefile.am which further generates Makefile.in and at last Makefile.
Please help me in solving the error and also let me know if my understanding about the configure and makefiles is incorrect
configure scripts explore the environment in which a program is to be built. They then accordingly adjust tools called, options used and libraries linked, among other things. Some of the information is obtained by trying to execute programs with certain options; failure of a program to run is the intended way of obtaining the information that the given program is not available or does not take those options. Therefore it is not necessarily an error if one of the things doesn't work and produces an error; it may be one of the legitimate outcomes, and the (error, here) exit code of the compiler will be used to modify the Makefile accordingly — for example by omitting -V ;-).
Does the configure script actually stop there, or are you just observing the error in the log file? If you search for gcc -V on the web you'll find examples of configure scripts failing actually later (for unrelated reasons) which have the same "-V error" line in it. Could that be the case? I would assume that errors which actually cause configure to stop and not produce a Makefile should be visible on the command line, not only in the log file.
As an aside it is worthwhile to run ./configure --help and look through the options. Some may improve the build process or the result; for example you can usually tell configure that you are using gcc, gnu ld and so on, or that you don't need certain features (like X25 ;-) ).
You should look into the makefile of your project, identify where the misspelled -V option is and replace it with -v (lowercase). As pointed out by others in the comments -V is not a compiling flag, but gives back the compiler's version.
So I've upgraded to a newer version of Linux kernel using Yocto. The new kernel version is for 4.1.15 and runs on an iMX6 chip. I've also included openssh-server, tools-sdk, and tools-debug for development recipes. The problem is that when I connect to build I get the following error:
loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))'
failed
Now if I type into the command prompt sh -c "LANG=en_US" I get the same error as above. If I type in sh -c "LANG=/usr/lib/locale/en_US" then I do not get an error. When I type locale everything is listed as POSIX and when I type locale -a I get:
C
POSIX
en_GB
en_US
The last two are stored under /usr/lib/locale. My version of gcc is 5.2 and my glibc is v2.22. I've looked all over the internet for other solutions but they are either for Ubuntu where the package manager comes in handy or it's some really specific fix like editing a file that I don't have in my Yocto build.
Edit:
The machine is for a SMARC-FiMX6 SoM and the instructions are here. I'm not sure what branch of Yocto is being pulled down.
After troubleshooting the problem is from the glibc library. A patch, #114739, is on the openembedded website which details what to do to fix this issue. Just patch the file, rebuild, and the issue is fixed. See here for details, the patch is at the bottom of the page.
I have the MinGW install previously working fine with MSYS. They are installed properly and functioning just well.
I installed the PortAudio library and did the install and got the success message after:
./configure
make
make install
When I try to compile samples:
c:\c>gcc patest_mono.c -o pa.exe
patest_mono.c:50:23: fatal error: portaudio.h: No such file or directory
#include "portaudio.h"
^
compilation terminated.
I'm new. I have a feeling I might be doing something fundamentally wrong with the way I'm trying to create the exe from compiling. It's been somewhat of a puzzle quest so far, but I've tried to figure it out and think I am close but completely missing something.
PATH variable ?
In the PortAudio MinGW build instructions I noticed
"The above should create a working version though you might want to
provide '–prefix=<path-to-install-dir>' to configure. "
I've tried adding C:\MingW\PortAudio into the user path. Doesn't work.
I've also tried running the commands in Bash and they come back with an error message "No Rule to make target 'paexpink'" either with the make command, and with gcc .c -o .exe I just get the same error message as compiling straight from the cmd prompt.
I found another source on stack overflow thread with no answers, but the user had commented that http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyaudio provided them a solution but I tried installing the 5 cpython binaries and under the assumption I did it right, it didn't work either.
Thanks for your help,
Julian
To build and install portaudio, you need to add -prefix=/c/<"path to base of the MinGW directory"> to the ./configure line.
For example: ./configure -prefix=/c/MinGW/
then continue the installation by doing
make
After that, do the
make install
and that should install the portaudio files into MinGW.
After it has finished installing, you need to add -lportaudio to the compile command whenever you compile any programs that you want to use PortAudio in.
For example: gcc -o test test.c -lportaudio
I just figured out how to do this today, so I may have accidentally forgotten a few steps.
This might have passed to the unix and linux stack exchange, but since it involves compiling, i am posting it here.
I want to compile usbserial, usb-wwan, and/or qcserial drivers for 2.6.35-9 Debian for ARMv7.
First problem, there is no 2.6.35-9 driver in the apt-get repos. I tried to compile with 2.6.32-kirkwood, while compilation works, insmod / modprobe, including -f, respectively --force switch fails, with the message :
insmod: error inserting 'usbserial.ko': -1 Invalid module format
I have looked up this and this. In this question, I was pointed to Debian 2.6.35-9 headers, but they did not install, for some dependency problem (Error message : Couldn't resolve dependency, without a list of missing dependencies). So I opened the .deb with ar, but it does not contain anything besides under data.tar.gz a /usr/share/doc ... etc - so no usable header files (or am I missing something?)
I am doing the compilation on the target machine (A Mirabox from Marvell) itself.
So, my question is,
Can I download the Ubuntu 2.6.35 headers? Ubuntu uses Debian core, and the linux kernel is the same, with adaptions to the distro, or it is a fatal error? Is there any Armv7 header for a 2.6.35-9 at all?
If not, then what do I do? Where do I get the correct header files?
Also, 2.6.35 code for usbserial / qcserial is buggy anyway. I was using the code from the 3.2 kernel, thinking the errors might have been fixed. Was it a bad choice? If so, what to do
Because the Mercurial Installer will not work on an old Windows 2000 system, I'm trying to build it from source. Its complaining that the C Compiler doesn't recognize the option -mno-cygwin. My version of gcc is 4.6.1. and MinGw is only two months old.
Followed these steps: https://www.mercurial-scm.org/wiki/BuildingOnWindows
F:\mercurial-2.0.2>python setup.py build
running build
running build_mo
warning: hgbuildmo: could not find msgfmt executable, no translations will be built
running build_py
package init file 'mercurial\__init__.py' not found (or not a regular file)
package init file 'mercurial\__init__.py' not found (or not a regular file)
running build_ext
building 'mercurial.base85' extension
f:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -If:\python27\include
-If:\python27\PC -c mercurial/base85.c -o build\temp.win32-2.7\Release\mercurial\base85.o
**cc1.exe: error: unrecognized command line option '-mno-cygwin'**
error: command 'gcc' failed with exit status 1
From a comment by a TDM-GCC MinGW distro developer:
As of the 4.6 series, GCC no longer accepts many unrecognized options
or flags. TDM-GCC has never "supported" -mno-cygwin; now, it will
complain about it. This is also true for libtool flags such as
"-no-undefined".
So you may have to use a somewhat older GCC version that will ignore the meaningless option, or fix the build scripts so they don't use that flag (which would never be necessary with the MinGW compiler anyway).
As a follow-on note, it looks like the Cygwin compiler stopped supporting -mno-cygwin starting with GCC 4: http://www.cygwin.com/ml/cygwin/2009-03/msg00802.html
So that option has been more or less useless for a couple years.
You not to forget this step before running "python setup.py build"?
If using mingw, a setup.cfg needs to be created which directs setuptools to use it:
cd mercurial
echo [build] > setup.cfg
echo compiler=mingw32 >> setup.cfg