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
Related
I'm trying to cross-build LÖVE (https://love2d.org) for an ARM Linux device (Rockchip RK3066) from Ubuntu 16.04.
As the documentation says, I installed all dependencies on Ubuntu and was able to build it (for Ubuntu, as a test). Now I'm going for the cross-build.
Before building, I have to run ./configure. So far I've been able to get the toolchain's gcc compiler to be accepted, but when it looks for the dependencies, I get this error:
checking for luajit5.1... no
checking for luajit51... no
checking for luajit... no
configure: error: Package requirements (luajit) were not met:
No package 'luajit' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables lua_CFLAGS
and lua_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Could this be fixed by cross-building luajit for the device and add it to the toolchain binaries, or could I just try to make the ./configure script look for the luajit I installed in Ubuntu?
If it's the latter, would someone kindly point me on the right direction? I've opened like 20 pages already with a similar error message and none of them had a valid answer.
Thanks a lot in advance.
I want to cross-build partprobe (e.g. parted-3.1 from [here] ) for an ARMv7-controller but keep getting error messages concerning libuuid and uuid_generate.
Actually I only need partprobe which may not even rely on that uuid_generate function, but I don't see any options in the configure script to disable any features.
I've successfully cross-built software before using the BPS as well as using the ARM toolchain provided by my distribution (Mint 17).
Here's what I've tried so far:
1) Using the manufacturer's BSP
I have a board support package that provides libraries and headers as well as a toolchain:
/path/to/bsp/_rootfs/lib/libuuid.so.1
/path/to/bsp/_rootfs/lib/libuuid.so.1.3.0
/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/linux/uuid.h
/path/to/bsp/linux-devkit/am3352/bin/
When I invoke
./configure \
--libdir=/path/to/bsp/_rootfs/lib/ \
--includedir=/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/ \
--bindir=/path/to/bsp/linux-devkit/am3352/bin/ \
--with-sysroot=/path/to/bsp/_rootfs \
--host=arm-linux-gnueabihf
I get the following error
checking for uuid_generate in -luuid... no
configure: error: GNU Parted requires libuuid - a part of the util-linux-ng package (but
usually distributed separately in libuuid-devel, uuid-dev or similar)
This can probably be found on your distribution's CD or FTP site or at:
http://userweb.kernel.org/~kzak/util-linux-ng/
Note: originally, libuuid was part of the e2fsprogs package. Later, it
moved to util-linux-ng-2.16, and that package is now the preferred source.
The uuid.h and libraries are available, so I thought the configure script should not complain, but the error seems to be misleading. The header uuid.h is available but does not contain a uuid_generate function declaration, while the library contains such a function (checked with nm -D).
I'm not sure what to do with that...does the BSP contain incompatible version of the header and the library?
However the busybox binary contains wget which seems to use uuid_generate...at some point it must have worked.
Replacing the original uuid.h with a uuid.h.in from the /path/to/bsp/docs/am3352/licenses/e2fsprogs/ (which contains uuid_generate) still results in the same error.
2) Using the Linux distro's ARM-environment
I also tried using the ARM-toolchain provided by my Linux distribution (packages gcc-arm-linux-gnueabihf, libuuid1:armhf)
aptitude install uuid-dev:armhf
shows conflicts with the x86 package of uuid-dev, but there are already available:
/usr/arm-linux-gnueabi/include/linux/uuid.h
/usr/arm-linux-gnueabihf/include/linux/uuid.h
/lib/arm-linux-gnueabihf/libuuid.so.1
/lib/arm-linux-gnueabihf/libuuid.so.1.3.0
BTW: None of those two header files includes a string uuid_generate, while the libraries do.
Invoking
./configure host=arm-linux-gnueabihf
runs without errors, but creates a Makefile that lacks any info on the cross-build environment.
BTW: Invoking make anyway exits with error; trying the same with the current source code from git://git.savannah.gnu.org/parted.git configures and builds successfully, but no magic involved: the result are libraries/binaries for x86 and not for ARM.
Right now I'm at my wits' end - so my question is:
Can someone see the problem(s) I'm missing?
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 recently switched my PC at work from Ubuntu to Arch Linux.
And I am now getting the following error (I am using stack to build my project):
setup-Simple-Cabal-1.22.4.0-ghc-7.10.2: Missing dependency on a
foreign
library:
* Missing C library: HSrts-ghc7.10.2
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
As far as I understand it, the difference in Linux Distribution should not cause any issue.
Things I have tried:
-add the path where the library is with --extra-lib-dirs
-make sure that the version of stack/ghc are the same acrose both systems
-tried unsucesfully to find a relevant difference between the 2 systems
(gcc version was different but didn't change anything)
I have a docker container based on ubutu where it builds without an issue.
The only thing I can think of is that this library gets handled differently from some random C-library since it contains the Haskell-Runtime. But I have no idea what this difference would be. Or how a differnent handling would cause an issue on my Arch System.
Here my .cabal file (the folder also contains the whole project):
https://github.com/opencog/atomspace/blob/master/tests/haskell/libExecutionOutputTest/opencoglib.cabal
Okay i figured out a workaround, instead of specifiyc the library in the .cabal file:
...
extra-libraries: HSrts-ghc7.10.2
...
you add it to your stack.yaml file:
...
ghc-options:
package-name: -lHSrts-ghc7.10.2
...
If you also have a exectuable defined in your .cabal file this will break the executable, since the library is not only included in the library. And including the runtime library in an executable results in an instant segementation fault.
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.