Well, this is not a promising start, to have my question title marked as 'frequently downvoted' but I can't make it more clear. So I try it anyway. Here's the problem:
ipkg update
Downloading http://ipkg.nslu2-linux.org/optware-ng/bootstrap/Packages.gz.
Segmentation fault
Some info about the architecture:
uname -a
Linux syno 3.10.105 [...] x86_64 GNU/Linux synology_braswell_216+II
First I tried the easy way with the package 'Easy Bootstrap Installer' but the command 'ipkg update' resulted in the segmentation fault error, even directly after resetting the nas to factory settings.
Then, as root and after removing all traces of previous ipkg installations (I think), I tried "wget http://ipkg.nslu2-linux.org/optware-ng/bootstrap/buildroot-i686-bootstrap.sh" and executed it. The script runs well, and then reports the same error 'segmentation fault' in line 18 that does '/opt/bin/ipkg update'.
I did not find an answer, though I searched with diligence. And that baffles me. Am I the only one with this problem? I do hope I'm not annoying this friendly community, but I've run out of options. So if anyone can help...
I've solved my problem in an unexpected way. I found entware on github for synology. I removed the /opt directory, and executed generic.sh for the x86_64 architecture. It ran without errors and the segmentation fault is gone. Now I have an up to date repository with more packages! Thank you, entware team.
Related
Using a stock install of Chapel (via Homebrew) on a Mac running Big Sur. Tried to compile one of the example programs:
chpl /usr/local/Cellar/chapel/1.27.0/libexec/examples/hello.chpl
followed with
mv: rename /var/folders/81/9s9zv6450td9kgh_znllq52000037c/T//chpl-username.deleteme-nJkMMc/hello.tmp to hello: No such file or directory
error: mv /var/folders/81/9s9zv6450td9kgh_znllq52000037c/T//chpl-username.deleteme-nJkMMc/hello.tmp hello
error: Make Binary - Linking
Looks like a simple fix, but would appreciate suggestions. (And annoyingly, am trying to (eventually!) do a local compile of a package I contributed to)
R.
As noted and verified in the comments above, this seems to have been a recently discovered issue in our code base that can be worked around in homebrew for the time being by doing a brew update. It ought to be fixed in a more principled manner in Chapel 1.28.0 and onwards. If others see this failure mode going forward, please consider opening a GitHub issue on the Chapel repository so that we can help you work through it.
I am trying to install ezbounce on an SSH Shell. (Host has OK'ed use of the bouncer)
(I do NOT have sudo, however, my host is lenient and I can get things ran. If possible, I prefer a solution that does NOT require sudo or equivalent.)
I have finished ./configure , and am on the make step.
when I go to make the file, it errors with the following:
https://pastebin.com/YetM6nGN
I found a possible solution to the problem here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219298
The solution seems to be centered on the fact that GCC++/GNU make calls its latest version as opposed to the newer one.
They have an included patch, but I am honestly clueless how this gets applied.
Any help fixing the error via here or directly editing the makefile is greatly appreciated.
My makefile: https://www.dropbox.com/s/u75toiigd4v5wgl/Makefile?dl=0
So I had some help from an external source (Thank you discord communities!)
The patch listed above is for FreeBSD ONLY! (As I was made aware)
For Non-FreeBSD Ports, the fix (if your makefile looks like mine) is to edit line 32 to the following: CXX_OPTIMIZATIONS = -std=gnu++98 -O2
There is some error looking items in console that follows, but the build is successful, so I'm gonna assume they are moot.
It honestly was a confusing little puzzle for your average user, but there ya go :)
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
I have been trying to install Git using Homebrew on OSX Lion for over a week now, with no luck. Other installs have been fine, what am I doing wrong please?
MacBookPro:Rails pingu$ brew install git
==> Downloading http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2
curl: (22) The requested URL returned error: 503
Error: Failure while executing: /usr/bin/curl -f#LA Homebrew\ 0.8\ (Ruby\ 1.8.7-249;\ Mac\ OS\ X\ 10.7) http://kernel.org/pub/software/scm/git/git-1.7.6.1.tar.bz2 -o /Users/pingu/Library/Caches/Homebrew/git-1.7.6.1.tar.bz2
If you follow the link that 'brew install git' spits out - you will find that the website is "Down for maintenance". That's why it is not working!
A clever SO'er found the solution to this problem by using a mirror for the tar. You can read his instructions in this answer
If you go to the URL yourself you will notice the huge Maintenance warning. This is probably connected with the recent security breach on kernel.org.
Just try again later when the kernel.org admins are sure that the systems are save.
It is worth keeping a chart of the major status codes, handy. A good source is https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
404's are well known enough, but the 500 series, as indicated, reflect a server problem. Good web developers should also be looking at their logs, and if, for example, they are getting regular hits from a link to a location that they now no longer use, they should return a '301' (Moved Permanently), which may trigger the referring linker to update their link (or not).
I am trying to run git from the command line on my Windows 7, 64 bit machine. It works fine for the most part. I tried pushing my local changes up to my private repository in the cloud.
The command I am trying to run is git push origin master
I use Cygwin 6.1 and it is causing the following error. Presumably related to the fact that I am running on a 64 bit machine
0 [main] git-remote-http 6168 fork: child -1 - died waiting for longjmp before initialization, retry 10, exit code 0xC0000135, errno 11 error: cannot fork() for send-pack: Resource temporarily unavailable
I followed the suggestions here to update my rebaseall file and reran the rebase command. But it didn't really seem to have helped.
Can anyone else reproduce the problem or have found a solution?
Thanks in advance for the help.
The Cygwin mantra I used is "fork failures are rebase issues". longjmp is not the issue, fork is. Rebase is the only solution unfortunately. In the past I have used custom scripts to build the rebase list. I do this because you may be missing some DLLs, especially if you have hand-built stuff. You can build a list with find and then pass it in to rebaseall with -T. You should also consider trying a different base address other than the default one in rebaseall, look at the -b option. 64-bit machines seem to require larger spacing than 32-bit ones and so the default didn't work well for me.
Also if you change any DLLs on your system at all, you'll need to rebase again.
Note: Even after all this fork can still fail in Cygwin. Virus scanners inject their DLLs which screw things up and Windows address space randomization doesn't help either.
The answer mfisch gave worked wonders for my problem.
A quick google search yielded this result which let me git push again in no time at all. The required packages came with the default cygwin install, so I didn't even have to install anything.
The other alternative is to use the msysgit distribution, which will allows you to make any git command without depending on the cygwin environment.
See also "Difference between msysgit and 'cygwin + git'?".