I'm following the directions here. In the last step it says
The kernel source tree will now be found under the ~/rpmbuild/BUILD/ directory. "
However, when I go into this directory, I see nothing. Any ideas? I've done everything else the page says.
You may be running an old version of rpmbuild, which used /usr/src/packages/ instead of ~/rpmbuild.
Related
I am trying to build Linux for my Raspberry Pi 3.
When I do make, I get the below error.
make[2]: /home/rohit/workplace/rp/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-gcc: Command not found
A little background will help. I am following this link . To summarize this is what I ran.
make raspberrypi3_defconfig
make linux-menuconfig
make
From the error I get that the cross gcc is not available at the path as it should be. But I am not sure what I am missing.
The complete log of the make is pasted here. The output/host/usr/bin folder also doesn't contain arm-buildroot-linux-uclibcgnueabihf-gcc, though it does contain arm-buildroot-linux-uclibcgnueabi-gcc. I have pasted the contents of the folder here.
Please help.
i was having this problem and after a make clean the problem was solved. I think the error was because different toolchains used in different builds. The manual says that is one of the cases that you have to do a make clean
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
Yt works early.when I try to use gcc commend it show me. I already uninstalled and re-installed gcc 4.8.
this is error:
as.exe - entry point not found
the procedure entry point __printf__ could not be located in the dynamic link library c:\mingw\bin..\lib\gcc\mingw32\4.8.1\..\..\..\..\mingw32\bin\as.exe"
this is code:
#include <stdio.h>
int main(){
}
I know it's too late to answer, but maybe it can help someone else.
I have just faced this problem, it is solved that change the directory name (in MinGW directory) from mingw32 to mingw32old. Because these two directory has as.exe in their bin directory, so they conflicts, and occures error. However, now it is working,
hope benefits to your problems.
(I'd rather post this as a comment, but I don't have enough reputation yet.)
The error seems to be related to the start of as, not to your code. You can check by running as --help (it should display a long list of options). Assuming this command also fails, continue with reading.
The whole error looks a bit weird, but I guess your issue is caused by multiple conflicting DLLs in your PATH. You should be able to test this hypothesis by going into c:\mingw\bin, clearing PATH completely (set PATH= in the Windows shell; export PATH= in Bash) and trying to execute as --help again. If that helped, you need to identify what program in your PATH is causing this and either remove it from PATH completely, or remember to set a custom, short, non-conflicting PATH everytime you want to use your mingw installation.
Sometimes as.exe can also be sourced from c:\MinGW\msys\1.0\bin\ which might conflict with c:\MinGW\bin\. I suggest to experiment as #DavidMacek did - remove c:\MinGW\bin from PATH and reboot the shell and then type as --help to see if things are fine. If things are fine. Goto your environmental variable and "move up" c:\MinGW\msys\1.0\bin\ above c:\MinGW\bin\ to let msys take precedence.
I just added a path to the as.exe to the system environment variables and it worked.
In my case it was path to the Code blocks gcc compiler on Windows 10:
C:\Program Files (x86)\CodeBlocks\MinGW\bin
warning: noob question ahead :-)
I was trying to run go get github.com/astaxie/beego but it does nothing. I have been running examples I picked up from the internet and I installed gotour successfully. Any idea why?
Turns out my setup was messed up. I purged everything and installed golang using this nifty script: https://github.com/moovweb/gvm. It takes care of everything. Thanks #peterSO for the help.
If it doesn't show anything, it doesn't mean nothing works. Try doing the same with '-v' flag
go get -v github.com/astaxie/beego
Besides, all your downloads will be saved (most probably) somewhere to your '~' directory ('~/go/src' in my case), not in your current terminal directory
if on Ubuntu/Debian?, try the golang package for installing go. it seems to work for me quite well.
I'm following a guide from The Mathematica Journal that describes how to use Mathematica with the Lego Mindstorms NXT. I have some trouble getting started and got stuck with the SerialIO package.
I use Mac OSX and I have installed the package to:
/Applications/Mathematica.app/AddOns/ExtraPackages/SerialIO/
The command Needs["SerialIO`"] gives me the following error message:
LinkOpen::linke: Could not find MathLink executable.
And trying
SetDirectory[FileNameJoin[{$InstallationDirectory, "AddOns", "ExtraPackages", "SerialIO", $SystemID}]];
Does not help either, it gives:
SetDirectory::cdir: Cannot set current directory to /Applications/Mathematica.app/AddOns/ExtraPackages/SerialIO/MacOSX-x86-64.
There seem to be some problem with the alias/symbolic link in the SerialIO folder. By default they pointed to an absolute directory on the machine that this library was built on:
MacOSX-x86-64 -> /Files/schofield/Packages/SerialIO/Build/Mac/build/Deployment/Package/SerialIO/MacOSX
I tried deleting the alias and creating a symbolic link in the terminal:
ln -s MacOSX MacOSX-x86-64
Running the SetDirectory command again result in... no result, so I guess thats good. The commands seem to have been loaded as when typing Serial it want to autocomplete to SerialOpen etc.
However, using the command mybrick = SerialOpen["name of serial port"] does not put the NXT in connected mode (<> on NXT display). Does anyone else got it to work?
There was a problem in SerialIO in combination with Mathematica9. After some correspondence in may 2013, Wolfram Support find the problem and updated SerialIO for me. It seems logical that they also update SerialIO on their site. Please have a try and download SerialIO again and update. My OS is MaxOSX.