I can't seem to get debugging working on bochs. I installed it using macports. Specifically, when I launch bochs, the command line never appears.
I'm pretty sure I included the debugging variant when I installed it; but, I suppose I could have mis-typed it.
When I run port installed bochs, I get this
$ port installed bochs
The following ports are currently installed:
bochs #2.6.8_1+avx+sdl2+smp+term (active)
Which seems to suggest the debugging variant isn't installed; but, when I try to add the debugging variant, the response suggests that nothing need be done:
$ sudo port upgrade --enforce-variants bochs +debugging
---> Scanning binaries for linking errors
---> No broken files found.
Is there another way to verify the presence or absence of debugging, and add it, if necessary?
I believe the variant for bochs debugging is:
+debugger
In a standard bochs ./configure the option would be:
--enable-debugger
↳ https://github.com/macports/macports-ports/blob/master/emulators/bochs/Portfile#L51
Related
I need to setup a simple and compelling dev environment for small proyects written in Haskell in Windows machines for freshmen.
I have tried several ways to integrate Haskell into VSCode in Windows with no success.
I had a nice setup a few years ago, but I´m finding problems with dependencies recreating that environment:
Editor: Atom
Global binaries build using: stack with ghc-mod hlint stylish-haskell
Atom plugins: language-haskell, ide-haskell, ide-haskell-repl, haskell-ghc-mod
It seems that the "cool" way right now is Language Server Protocol + VScode. ghc-mod seems not to be mantained anymore, Intero has reached EOL, HEI is merging with another project... Having a stable and updated dev environment looks like a moving target.
So, the question is: does anyone have reproducible step-by-step instructions for having VSCode working with Haskell in Windows?
I will test any suggestion in a fresh Windows 10 64bits VM and report the results.
Note: VSCode + Docker container is not an option. Most of the student´s machines have 4GB RAM.
Thanks in advance.
There's a tool called ghcid (not to be confused with ghcide) that, while nowhere near a full-blown IDE, is pretty robust and provides some niceties like re-compiling on save and showing compile errors. It doesn't support go-to-definition though. It has a VSCode plugin.
Here's a possible way of setting up things in Windows:
Download the GHC 8.8.3 binaries for Windows from here.
Download the cabal-install 3.0.0.0 binaries for Windows from here.
Decompress them in some folder.
Add entries to your PATH environment variable so that it has access to the /bin folder of the GHC installation and to the folder containing the cabal executable.
Open a Powershell console.
Run cabal udpate
Run cabal install --install-method=copy --installdir=somefolder ghcid to install the ghcid executable, where "somefolder" is the destination folder. (If the installation fails, try running the command from a Git Bash or Cygwin terminal as a workaround.) Put the destination folder in PATH.
Open (or restart) VSCode and install the "Haskell Syntax Highlighting" and haskell-ghcid plugins.
Go to an example cabal project, use the Ctrl-Shift-P shortcut, and execute the Start ghcid action. The ghcid terminal will appear.
Example of a ghcid session showing an error:
The haskell-ghcid plugin can read a .ghcid file in the project root containing flags that should be passed to the ghcid command.
Extra instructions to set up code formatting:
Install the ormulu formatter by running cabal install ormolu --install-method=copy --installdir=somefolder. Again, make sure that the destination folder in in PATH.
Open (or restart) VSCode and install the ormulu plugin.
Now the "Format Document" and "Format Selection" actions in VSCode will use ormulu.
Another way of installing GHC and getting to ghcid and ormulu could be by using the stack tool, which handles GHC installation by itself.
A Unix (mac/Linux) user who has been forced to work on a windows machine here :)
I have scripted loads of work in GnuPlot and don't want to switch to other programs at this moment. I would appreciate it if you could help me know how to install GnuPlot On windows (more specifically windows 10). questions:
I know there are two options according to this page, Cygwin and MinGW. which one is better?
I have MinGW installed and I know I need to install one of the options from this page but I don't know which one(s)! and how.
I have searched the internet but it seems most of the search results are for compiling. I don't want to go through compiling and all the hassle.
I tried installing the binary from this link, and when I try to run the program this is the error I get:
Unable to execute file:
C:\Program Files\gnuplot\bin\wgnuplot.exe
CreatProcess failed; Code267.
The directory name is invalid.
I would appreciate it if you could give me a very simple stepwise installation (1 2 3 ...), preferably with visuals, and instructions.
P.S. A nice way to install Free, Libre, and Open Source Software (FLOSS) on Windows and keep them updated, is to use package managers like Chocolatey. There are GnuPlot chocolatey packages here. Just install choco as instructed here. Then use choco install Gnuplot to have the software installed.
You don't have to install MinGW or Cygwin. Actually packages compiled in MinGW are compatible with Windows. Just download the binary of gnuplot from Their repo and you are good to go.
Additional points:
When installing, check which terminals you want to set up; also
check if you want the installer to add the PATH variable to your
system. Also, create a desktop shortcut.
After installation, you should see the desktop shortcut. Clicking on it should open a terminal-based gnuplot (which hopefully you are familiar with).
Please note that I have used the x11 terminal (you can get this working by installing xming). There are other options such as windows and qt terminals, but I am not an expert on using these.
You should have Administrator rights on this machine.
Right click on MinGW, Run as Administrator, install - should be OK.
Good luck!
BR, Alex
You can try
$~ scoop install gnuplot
Installing 'Gnuplot' (5.4.5) [64bit] from main bucket
gp545-win64-mingw.7z (37.7 MB) [=======================================] 100%
Checking hash of gp545-win64-mingw.7z ... ok.
Extracting gp545-win64-mingw.7z ... done.
Linking ~\scoop\apps\Gnuplot\current => ~\scoop\apps\Gnuplot\5.4.5
Creating shim for 'gnuplot'.
Creating shortcut for GNUPlot (wgnuplot.exe)
'Gnuplot' (5.4.5) was installed successfully!
I installed YouCompleteMe for VIM via Vundle on my Mac with Mavericks. After Vundle did its magic i ran
./install.sh --clang-completer
which worked without any errors. The Python completion works fine, too. But the C Lang Family support does not seem to work. Also running
./run_tests.sh
gives me
Your C++ compiler supports C++11, compiling in that mode.
-- Found PythonLibs: /usr/local/Cellar/python/2.7.7_2/Frameworks/Python.framework/Versions/2.7/Python (found suitable version "2.7.7", minimum required is "2.6")
NOT using libclang, no semantic completion for C/C++/ObjC will be available
Does anybody know how to solve that problem?
Don't run the 2nd command
./run_tests.sh
It's will re-compile ycm_*.so without --clang-completer (that is default option).
To fix it, install again:
./install.sh --clang-completer
add your clang_library_path in .vimrc,such as
let g:clang_library_path='/usr/lib/llvm-3.8/lib/'
I have a 32-bit Fortran application that I need to run on a 64-bit ubuntu server. I have verified the application on a 32-bit ubuntu machine and it runs fine; however, I get the following error when I run in on the 64-bit server:
error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
Doing some research on this, I've tried the following with no joy:
sudo apt-get install libgfortran3:i386 which can't locate the package
Manually install a 32-bit .deb package of libgfortran (failed with
error about incorrect architecture)
Install getlibs and have it determine what the dependencies are
Run ldconfig -v which finds libgfortran.so.3 -> libgfortran.so.3.0.0 under /usr/lib/x86_64-linux-gnu:...
... and then try to change the path to LD_LIBRARY_PATH to that, which did nothing (though I have to say that my knowledge gets very sparce once we start talking about library paths...)
Check if ia32-libs are installed, which they are
removed and re-installed libgfortran, then randpkg --configure --pending and dpkg --path-include=/usr/lib/x86_64-linux-gnu.
I'd like to stay away from creating a 32-bit chroot if at all possible but at this point I don't if there is anything else to do that could keep me from having to do so...
Do any of you have an idea as to something else I could do? Thank you.
Try to install the package lib32gfortran3, as that would install the 32 bit version of the libgfortran library. Before starting the program, you may eventually need to set LD_LIBRARY_PATH="/usr/lib32:" but probably it will run also without this.
I'm not sure if this was an oversight on my part or something else; but here are the two steps that fixed it all:
Run sudo apt-get install gfortran on a 64-bit machine which will install the GNU Fortran Compiler
Recompile the application, on the 64-bit machine, using gfortran.
The strange part was that at this point I was still not able to just copy/paste the application file to other 64-bit machines and run it. Rather, I first had to separately install gfortran on each machine, even if I wasn't planning on compiling anything. Once gfortran was installed, the application would run, no matter where it was compiled... I presume that the libgfortran3 must have been some dependency...
I'm trying to remote debug an application running on arm9
So far I've been able to cross compile and execute gdbserver on my device.
get gdb (7.2) sources and extract them
./configure --target=arm-none-linux-gnueabi --with-expat=/usr/local/lib/
make
cd gdb/gdbserver
./configure --host=arm-none-linux-gnueabi
make
tftp gdbserver to my device
run and connect via gdb to the device
gdbserver "seems" to start correctly and attach itself to my helloworld application
When I try to gdb to the remote server, I get
"warning: Can not parse XML target description; XML support was disabled at compile time"
Obviously, the compilation didn't take into account expat. I'm really unsure about how to specify the expat library path to the configuration script.
(old question but I stumbled into it via googling the same problem)
The problem is the missing "expat" lib. This is hard to guess because :
this lib is optional for compiling gdb
the "expat" name has no clear connection to XML...
So install "expat-dev" (with your packet manager or anything) and then relaunch ./configure. Be careful to install the "dev" version since we are doing recompilation and need the include files.
To be extra-sure, it's possible to add the "--with-expat" to the ./configure call so that it will stop with an error if expat is not found.
Somehow it worked anyway
Also, create a file ~/.gdbinit with
file /home/username/path/to/exec/exec_name
set sysroot /path/to/libraries/running/on/target/device
target remote HOST:PORT
b main