I'm trying to install the xv6 OS on my macOS (version 10.14.3) following the instructions of this site, only with the newest versions of the needed files and when I'm getting at the binutils configuration stage I'm getting from my terminal:
Config.guess failed to determine the host type. You need to specify one.
Usage: configure [OPTIONS] [HOST]
Options: [defaults in brackets]
--prefix=MYDIR install into MYDIR [/usr/local]
--exec-prefix=MYDIR install host-dependent files into MYDIR[/usr/local]
--help print this message [normal config]
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [determined via config.guess]
--norecursion configure this directory only [recurse]
--program-prefix=FOO prepend FOO to installed program names [""]
--program-suffix=FOO append FOO to installed program names [""]
--program-transform-name=P transform installed names by sed pattern P [""]
--site=SITE configure with site-specific makefile for SITE
--srcdir=DIR find the sources in DIR [. or ..]
--target=TARGET configure for TARGET [TARGET=HOST]
--tmpdir=TMPDIR create temporary files in TMPDIR [/tmp]
--nfp configure for software floating point [hard float]
--with-FOO, --with-FOO=BAR package FOO is available (parameter BAR)
--without-FOO package FOO is NOT available
--enable-FOO, --enable-FOO=BAR include feature FOO (parameter BAR)
--disable-FOO do not include feature FOO
Where HOST and TARGET are something like "sparc-sunos", "mips-sgi-irix5", etc.
What can I do to solve it? does anyone have better and validated instruction for installing xv6 on macOS? (I've also tried this website and it didn't work of course.)
all I needed to do is:
Install xCode and agree the terms of use.
Download xv6 from https://github.com/mit-pdos/xv6-public.
Install MacPorts from https://www.macports.org/.
Open a terminal window where I downloaded the OS.
Install Qemu by writing sudo port install qemu.
sudo port install i386-elf-gcc gdb.
Replace the existing Makefile to a new one.
In order to run, write in the terminal window make qemu clean.
Related
I am trying to build (and later upload) a conda package which would contain my custom program that I have developed in C++.
Simplifying the problem, I have a following meta.yaml:
package:
name: CoolName
version: "1.0.0"
source:
path: ./source
requirements:
build:
- make
and the following build.sh:
make
I have two questions here:
1) How and where should I copy the binary which is a result of the make compilation so that it is indeed recognized upon environment activation?
2) How should I specify g++ as a dependancy? I would like to have this package be later available for linux-64 and osx-64... In the building process (in the Makefile) I am using only g++.
Edit
I have modified my build script to have:
make
mkdir -p $PREFIX/bin
cp my_binary $PREFIX/bin/my_binary
And now the conda-build is successful. However, when I later try to install the package locally with conda install --use-local I get:
Collecting package metadata (current_repodata.json): done
Solving environment: done
# All requested packages already installed.
But this is not true, my binary is not installed anywhere and is not recognized...
How and where should I copy the binary which is a result of the make compilation so that it is indeed recognized upon environment activation?
As you mentioned in your edit, install somewhere within ${PREFIX}
How should I specify g++ as a dependancy?
To use conda-supplied compilers (rather than your system compiler), use this:
requirements:
build:
- {{ compiler('cxx') }}
I would like to have this package be later available for linux-64 and osx-64... In the building process (in the Makefile) I am using only g++.
Note: On Mac, it will use clang++, not g++. Make sure your Makefile respects the ${CXX} environment variable instead of hard-coding g++.
However, when I later try to install the package locally with conda install --use-local I get:
That is strange. conda install --use-local CoolName should do what you want. But here are some things to try:
Double-check the contents of the environment you're trying to install it into:
conda list
Try installing to a fresh environment:
conda create -n my-new-env --use-local CoolName
Delete any obsolete versions of the package you might have created before you successfully built the package:
# Inspect the packages you've created,
# and consider deleting all but the most recent one.
ls $(conda info --base)/conda-bld/linux-64/CoolName*.tar.bz2
...then try running conda install again.
I am trying to use CLion on Windows and I installed my environment using cygwin but I'm getting this warning in the settings. Moreover, it's almost impossible to debug because the debugger just stops showing debugger info in the middle.
I had the very same problem. I wasn't able to make CLion work with gdb 7.10.x but I was able to make cygwin install gdb 7.8-1. My method should work to install any version you want.
The following steps describe the way I managed to do it, I'm a newbie using cygwin, so maybe some of them are unnecessary.
Create a cache directory for cygwin and place the cygwin setup.exe in it (in my case C:\cygwinCache). [Source]
Execute the setup.exe and follow the usual steps for installing from Internet. Select Install from Internet, select your cygwin root directory (in my case C:\cygwin64), create and select a directory inside your cygwin cache directory (in my case C:\cygwinCache\downloaded), select the connection option your Internet connection requires, then select any server with gdb available (I selected http://cygwin.mirror.constant.com) and click Next. This will download and parse a setup.ini file that contains the available packages in the server you selected. This setup.ini file will be located in your cache directory in a sub directory named after the server you selected (C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64).
From the link that #H. DJEMAI found (this one) download the gdb installation and source files of the version you want (I downloaded gdb-7.8-1.tar.xz and gdb-7.8-1-src.tar.xz). As a backup, I uploaded these files in here.
In the directory where the setup.ini file is located create the \release\gdb directory. In this newly created \release\gdb directory place both of the gdb files you downloaded in the last step. Now you have the gdb installation and source files in the following paths:
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1.tar.xz
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1-src.tar.xz
Open the setup.ini file, and look for a line with this string: # gdb. This section has the information of the gdb package and information about the files it may contain. It should look like this:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.9.1-1
install: x86_64/release/gdb/gdb-7.9.1-1.tar.xz 2550148 f62f65865a11757b945f431a3662e16d0357dc9a0cbc720d16f5e99543cd3231f34bacd245daeb113ad38501358d9b1e7d128a1a45871d02c2bfb1c15891fbcb
source: x86_64/release/gdb/gdb-7.9.1-1-src.tar.xz 17888340 b90d198404a0a16268b443f4a4ec9672dac1d531f3fbda848f807fee7c004f5394e1985253c64ab0cdc2dcf7c088645c60edbf8e9f39dce0f149bce4b11f5085
Now edit the file to make cygwin install the version you want. To achieve this modify the lines where it says version, install and source with the information of the files you want to install. I modified the lines after the [prev] string replacing 7.8-1 instead of 7.9.1-1 so cygwin points to the correct location. Note that the lines that start with install: and source: contain the relative location of the files you previously downloaded and placed in the \release\gdb directory. After this relative location the setup.ini file contains the byte size and SHA-512 of the specified file. You can get the bite size for your file in the file properties. To get the SHA-512 you have to use other software like this one. In the case of the 7.8-1 files I got the following:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.8-1
install: x86_64/release/gdb/gdb-7.8-1.tar.xz 2491984 4c8d81984fe2ccbf92614c857737a42c4ec0c4016a5f8cf1dbc0fd117a1978baa7a8eadd2415a6d52041a1eecbe6b4e1373ba6850db6584869311a5e02a6e3b2
source: x86_64/release/gdb/gdb-7.8-1-src.tar.xz 17669132 a71b6886774cb004baa7dc88ed767983a72fc94c7585bd79ff64c2bd2071c411cf0de76584c56aa3553d9541172eaf31f1dd142a6dedec50c5446ff2986c6d48
Don't forget to save the setup.ini file after you modified it.
Open the cygwin setup inside the cache directory. Now instead of selecting the install from Internet option select Install from Local Directory, then set your root directory and as local package directory select your cache directory (C:\cygwinCache\downloaded). It will parse the setup.ini file, and if you edited it successfully, it will show you the grid to install, upgrade or uninstall packages. If the parsing fails an error will be shown.
Look for the gdb package under Devel category, it should appear installed with a current version:
Click it where it says Keep until you see the version you want. Then click next, this will start the installation, when the process is done, click finish.
You're done. You can open the cygwin terminal and type gdb --version and see that the correct version is installed:
After all these steps, now you can open clion and go to Settings > Toolchains and see the result:
PS. I achieved this with cygwin setup version 2.873 (64 bits).
While LuissRicardo's answer seems like it will work, I stumbled upon a solution online that is a lot more straightforward. See: http://kennyroh.blogspot.co.uk/2016/04/cygwin-clion-gdb-current-version-is-gnu.html
Download gdb-7.8-2.tar.xz from http://cygwin.mirror.constant.com/x86_64/release/gdb/ and put it somewhere in your Cygwin filesystem.
Open a Cygwin terminal at that location, and run: tar Jxvf gdb-7.8-2.tar.xz. The instructions use zxvf, but that won't work for .xz archives.
cd into the folder you just extracted (for me this was just cd usr).
Run the command cp -R * /usr/ to copy this to the correct location in the filesystem.
Run gdb --version just to make sure it's set to 7.8.2. If it's not then maybe try restarting Cygwin, and if that doesn't work then maybe post on StackOverflow or something :p
I know that this should probably be very easy, and I have looked into the read me files and other files in cgdb like INSTALL that talk about isntalling cgdb. I was trying to install cgdb and the instructions said:
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
However, there is no such file inside of the file I got from running the git clone command. i.e. from running:
$ git clone git://github.com/cgdb/cgdb.git
I went inside that file to see the installation instructions and it says the following:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
and there is more I didn't paste.
The part that confuses me is the following paragraph:
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
does it mean I should run ./configure.in? I am honeslty a little scared of running it because I need to run it in as sudo plus, that file doesn't even exit in the code I got from git clone. This is what I do have in that directory:
➜ cgdb git:(master) ls
AUTHORS Makefile.am autogen.sh doc roadmap.txt
COPYING NEWS autorelease.sh indent.sh test
ChangeLog README cgdb lib
FAQ README.md config packages
INSTALL TODO configure.init release-todo.txt
➜ cgdb git:(master)
I did grep for config or config.in in that directory and it didn't yield anything useful.
I have also tried brew installing it but I ran into problems. When I cgdb the file and hit run it frozen at a print statment instead of moving on to the next command prompt for gdb as in (gdb). Anyone knows whats up? Is it because I am using go source file?
What have people done to have cgdb working on a mac?
Неу, yeah, the git source for cgdb doesn't come with the configure script pre-built. (The official release distributions do, however.)
If you have the right tools installed, you can fix this by running:
./autogen.sh
This will generate the configure script, and then you can install it as you would any other autoconf-based source package.
Forget about all that aggro with configuration and dependency libraries; install MacPorts and do:
$ sudo port install cgdb
They have 0.6.7 at the time of writing.
What worked for me was doing:
brew install cgdb
However, for me that was not enough to get it going. I needed to sudo it for it to run:
sudo cgdb
I would have never guessed I needed to sudo it...I figured it out because it was throwing me the error talked about in the following question:
gdb fails with "Unable to find Mach task port for process-id" error
I am trying to include ZMQ sockets in a Go app but both zmq4 and gozmq (the referred ZMQ binding libraries for Go) are giving me problems. I would like to understand why zmq4 specifically isn't importable on my system.
I am running a Windows 8 system and I used the windows installer from the ZMQ website for version 4.0.3. I am primarily concerned about getting zmq4 set up and here is the result of my "go get" query on the github library's location:
> go get github.com/pebbe/zmq4
# github.com/pebbe/zmq4
polling.go:4:17: fatal error: zmq.h: No such file or directory
compilation terminated.
This issue is not alleviated by cloning the Github repository - the error remains the same.
I know the issue has to do with the C library zmq.h that is located in the "include" folder of my ZMQ installation, but whether the dependency is held up by a pathing issue or an external tool issue is a mystery to me.
A similar error has come up in regards to node.js and is the solution I see others referred to, outside of node scripting, but it was unsuccessful in my case.
I've so far included the path to the "include" folder in my PATH environment variable and previously placed zmq.h inside of the zmq4 top-level folder. I don't have much of an arsenal otherwise to understand this problem because I am new to C and C-importing packages in Go
I wanted to do the same thing, but on Windows 7, and here is what I had to do.
Since the Go bindings are using cgo to integrate with zeromq, you need zeromq built with gcc. There are no pre-built binaries, so you'll have to build them yourself, with mingw or similar, but this process is easier than it may sound, and nicely described on the zeromq site.
As #photoionized pointed out, C_INCLUDE_PATH and LIBRARY_PATH need to be set when building the Go bindings.
(In my case, I ran into a problem when compiling libzmq with IN6_ADDR not being defined. The only solution I found was, inspired by this issue, to manually add the line #include <in6addr.h> to the windows.hpp file.)
The Windows installer version of ZeroMQ won't work with zmq4, you need to compile from source with gcc, I recommend using MSYS2.
Install and update MSYS2 following the instructions from
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
cd into zeromq src folder (C:\ path starts with /c/ inside the shell)
./configure
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread*.dll
/mingw(32|64)/bin/libstdc++*.dll
Here's updated steps for #user2172816's MSYS2 solution:
Install and update MSYS2 following the instructions from http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
Add C:\msys64\mingw64\bin to your Path (pkg-config is there)
Restart the msys2 shell to get the new Path
Download and unzip libsodium source: https://github.com/jedisct1/libsodium/releases
cd into libsodium folder (C:\ path starts with /c/ inside the shell)
./configure --build=(x86_64|i686)-w64-mingw32
make
make install
Add /usr/local/lib to PKG_CONFIG_PATH (export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig)
cd into zeromq src folder
./configure --build=(x86_64|i686)-w64-mingw32
Add
#ifdef ZMQ_HAVE_MINGW32
#include <winsock2.h>
#include <windows.h>
#include "netioapi.h"
#endif
To the top of src/tcpaddress.cpp
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go build in your project directory
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread-*.dll
/mingw(32|64)/bin/libstdc++*.dll
/usr/local/bin/libsodium-*.dll
maybe? /usr/local/bin/libsodium-*.def
An updated answer using MSYS2.
Install MSYS2 MSYS2 installation guide.
Make sure to choose the correct installation 32bit or 64bit.
Open the appropriate shell MSYS2 MinGW 64-bit or MSYS2 MinGW 32-bit. All further steps assume you are using this shell.
Update packages following instructions at the installation guide.
Install libtool pacman -Sy libtool.
Download zmq source code to a location of your choice.
Navigate to the zmq source folder.
To generate the configure file, run the autogen tool by running ./autogen.sh.
In the probable case that step 8 fails:
Find the file at fault (probably version.sh).
Replace line endings by (replace file by the actual filename).
cp file file.bak
tr -d '\r' <file.bak> file
If this fails you'll have to dive in the code and find the problem.
Run the configure tool ./configure.
In the probable case of failure. Comment out empty else clauses in the configure file.
Add Go to Path: PATH=${PATH}:<go bin directory>.
Install Go Package: CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
To install ZMQ in windows: Problem in Installing Golang ZMQ for windows - fatal error: czmq.h: No such file or directory
First of all, install the msys64. Download the software from https://www.msys2.org/ and install it on C:\msys64.
Then add C:\msys64\mingw64\bin to PATH environment variable of the windows.
Then run the following commands (in CMD) one by one.
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
pacman -S base-devel gcc vim cmake
pacman -S mingw-w64-x86_64-libsodium
pacman -S mingw-w64-x86_64-zeromq
Finally, run the Go install command:
go get github.com/pebbe/zmq4
Finished.
I'm trying to install the new Cabal in Windows 7. It successfully installs 1.18.02, but when I run "cabal --version" it shows 1.16. The folder C:\Users\me\AppData\Roaming\cabal\bin is at the front of my PATH.
When I directly run the 1.18 executable, I get a bunch of "cabal.exe does not exist" errors.
How can I configure Cabal to use version 1.18 by default?
There is a path conflict due the way haskell platform installs cabal.exe
As seen in this ticket
To fix it:
Delete `C:/program files(x86)/Haskell platform/lib/extralibs/bin/cabal.exe.`
In any case, you can use search tool to find which cabal.exe to delete.
I used cabal-dev to install cabal 1.18 to a sandbox, such that C:\cabal-dev\cabal-dev\bin contains the latest (1.18) cabal executable. I then set C:\Cabal-dev\cabal-dev\bin as the first Variable value in the "Path" variable in "systems variables" (as opposed to the "PATH" variable in "user variables"). That worked for me, and allowed me to keep the older build of cabal intact, (in case its needed later).
It worked for me. Good luck. Here are my exact steps:
Install cabal-dev
open command prompt anywhere
execute following command: “cabal install cabal-dev”
Install new cabal
create directory: c:\cabal-dev, cd to it
execute following command: “cabal-dev install cabal-install”
Set new, upgraded cabal path as higher priority
Close any open command prompts
run: Sysdm.cpl
Go to the “Advanced” tab
Click “Environment Variables”
Select the “Path” variable listed in the “System variables” (lower) windows
Click edit
Add following string to the beginning of the variable value:
“C:\Cabal-dev\cabal-dev\bin;”
Ok, Ok, Ok
Ensure latest cabal is being run:
Open command prompt (anywhere except c:\cabal-dev\ *)
execute following command: “cabal –V”
cabal version should be 1.18.0.2
One other possible cause of this error (aside from the cabal in extralibs problem described in another answer) is that the ld in your path can't read the .o files that GHC produces.
I hit this problem with GHC 7.8.1 RC1, and could see this going wrong by running cabal install with -v3. The 'ld' on my path was coming from Haskell Platform 2013.2.0.0.
Adding mingw\bin from the new GHC's directory to the path fixed the problem.