include "P16F84A.inc"
cblock 0x33
V1
V2
V3
endc
movlw 3
movwf V1
movlw 4
movwf V2
movf V1,W
addwf V2 , W
movf V2,0
movwf V3
end
Clean: Deleting intermediary and output files. Clean: Done. Executing:
"C:\walaa\test.asm" /q /p16F84A "test.asm" /l"test.lst" /e"test.err"
Could not spawn langauge tool. Check command-line options. (193)
BUILD FAILED: Fri Dec 04 16:29:59 2020
The Original Poster does not include enough information to know for certain.
That aside, this kind of question about Microchips MPLABX has become common recently because support for the MPASMWIN assembler has been removed from MPLAX v5.40 and later.
The MPASMWIN tool chain cannot be added to these versions of the MPLABX IDE.
MPASMWIN support is present in MPLABX v5.35, the last version it was available.
The only tool chain for PIC 8-bit assembly language projects is pic-as(v2.xx).
This tool chain is part of the XC8 v2.3x C compiler installation.
Note: The pic-as(v2.3x) tool chain does not seem to be installed by default when the XC8 compiler is installed. In most cases the IDE requires the user to manually install this tool chain. That you may need to do this step is not documented by Microchip.
It would seem that Microchip's attitude is that if you are smart enough to use assembly language with obsolete controllers you should be smart enough to figure out how to install the tool chain without step by step instructions.
It's because you have MPLAB installed in the windows folder and the asm, linker and header are installed in root C:. MPLAB cannot find them.
Related
Disclaimer: Please read question carefully, This question has a twist so read it till end.
So JSON-C is one of the highly popular library to work on JSON using C programming. Basic illustration on current work, whatever code building here is for multi-platform. Currently Linux & Windows are supported platform and I have small issue with Windows related JSON-C part.
I'm using Cygwin for Windows development, and when I compile JSON-C code as per provided instruction on it's GitHub page, using CMAKE it works out quite good and build system is able generate DLLs for Windows. But if you have worked with Cygwin then you must know that whatever is built using Cygwin, will have dependency on it's run-time environment (cygwin1.dll) (Why does GCC-Windows depend on cygwin?) and it won't be an independent DLL that can be moved around to different system with same architecture. So with this dependency on Cygwin if my project is built on Windows platform, I have to carry around either Cygwin Run-Time Env. or I have to make sure Cygwin installed on target system for smooth execution. This sort of dependency I do not wish to have for my project, it can ruin user experience.
So what I want as help here, Is there a way to build JSON-C independent of Cygwin (run-time environment)??
NOTE: I already know that, if using Cygwin one wishes to create such an independent DLL for Windows then that can be done using few parameters to compiler and some additional macros placed in-front of function declaration as described here Creating a DLL in GCC or Cygwin?
But I don't see such support in source code JSON-C for Windows. So I was just wondering if JSON-C Dev team has kept some provision via build-system then I'm keen to know that part.
PS: I have not dipped into JSON-C build system yet due to my other development, so if anyone out there (my beloved community) has anything on this then please share, that would be terrific.
EDIT
Forgot to mention the version I'm using :p
json-c-0.13.1-20180305
I am able to build JSON-C 0.14-20200419 (from https://github.com/json-c/json-c) under MSYS2 with MinGW-w64 - both static and shared - using these instructions (replace /usr/local as needed):
INSTALLPREFIX=/usr/local
mkdir -p build_static build_shared &&
cmake.exe -Wno-dev -GNinja -DCMAKE_INSTALL_PREFIX:PATH=$INSTALLPREFIX -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=OFF -DBUILD_TESTING:BOOL=OFF -S. -Bbuild_static &&
cmake.exe -Wno-dev -GNinja -DCMAKE_INSTALL_PREFIX:PATH=$INSTALLPREFIX -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_TESTING:BOOL=OFF -S. -Bbuild_shared &&
ninja -Cbuild_static install/strip &&
ninja -Cbuild_shared install/strip &&
echo Success
If you don't have ninja you can probably also use -G"MSYS Makefiles" and use make instead of ninja.
Note that MinGW-w64 is different from Cygwin in that it compiles to native Windows binaries without dependancies on a compatibility layer (like Cygwin's cygwin1.dll). The following screenshots illustrates this:
I've been trying this for over 5 days and I have no idea how to get this to work. I had successfully installed boost once, then I got my computer re-imaged and now it's just not happening. I have Windows 7 Enterprise, and 64-bit operating system.
I downloaded boost from here sourceforge
unzipped it into program files.
I then went to the VS 2013 Native Command prompt. Changed directory to boost tools/build
Ran bootstrap.bat
I then ran ./b2 address-model=64
but it did not give me directories for the compiler and the linker like last time.
I then ran ./b2 --prefix=C:\ProgramFiles\boost_1_58_0
but again nothing happens. I get the following errors:
Warning: No Toolsets were configured.
Warning: Configuring default toolset ""msvc"
Warning: If the default is wrong, your build may not work correctly
warning: Use the "toolset=xxxxx" option to overrride out guess
warning: for more configuration please consult
I have no idea why this worked the first time I had done this and why this isn't working now. Can someone please help me out. I know nothing about Unix but I need to install this so I can use the libraries.
I compile boost with both mingw (64 bit) and msvc 2013 pro. I have never in my life used the vs command prompt to build boost with msvc. Here are my commands to build 64 bit binaries on both toolchains.
First go into the boost folder and just double click bootstrap.bat. This should run and build bjam/b2. Nothing special required and doesn't matter what compiler this gets built with.
Then simply run, in a normal command prompt:
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 release stage
Where -a forces rebuild all, -j8 means for the build to use 8 cores (adjust this based on your processor capabilities), toolset is obvious, layout means how to structure the naming of the output files, address-model is obvious, stagedir is where to output the built binaries (either relative or absolute path) and release stage is the type of build the system. See more here.
Same thing but using 64 bit mingw.
bjam.exe -j8 --toolset=gcc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\x64 release stage
You can even go on to build additional libraries with a second pass tweaking your arguments. For example, after I've built the core libs with the above command, I run the following command to build in zlib and gzip support.
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 --with-iostreams -s BZIP2_SOURCE=C:\dev\libraries\cpp\bzip2-1.0.6 -s ZLIB_SOURCE=C:\dev\libraries\cpp\zlib-1.2.8 release stage
Anyway that's just as an example. I linked to the full docs for the build system. Try building using these commands NOT inside a vs command prompt. If you still have problems then please post specific errors.
A note about MSVC
So, msvc compiler + boost supports a type of linking where it will automatically include additional libraries that it knows it needs. I believe boost does this by using the #pragma directive in headers. For example you might use boost::asio configured in such a way that it needs boost::system (for error codes and such). Even if you don't explicitly add boost::system library to the linker options, msvc will "figure out" that it needs this library and automatically try to link against it.
Now an issue arises here because you're using layout=system. The libraries are named simply "boost_" + the lib name, like "boost_system.dll". However, unless you specify a preprocessor define, this auto linking will try and link to a name like "boost_system_msvc_mt_1_58.lib". That's not exact as I can't recall the exact name, but you get the idea. You specifically told boost to name your libraries with the system layout (boost_thread, boost_system) etc instead of the default, which includes the boost version, "MT" if multithreaded, the compiler version, and lots of other stuff in the name. So that's why the auto linking feature goes looking for such a crazy weird name and fails. To fix this, add "BOOST_AUTO_LINK_NOMANGLE" in the Preprocessor section of your C++ settings in visual studio.
More on that here. Note that the answer here gives you a different preprocessor definition to solve this problem. I believe I ended up using BOOST_AUTO_LINK_NOMANGLE instead (which ended up working for me) because the ALL_DYN_LINK macro turned out to be designed as an "internal" define that boost controls and sets itself. Not sure as it's been some time since I had this issue, but the define I provide seems to solve the same root issue anyway.
I downloaded Eclipse Luna for 64-bit Mac OS X just a few days ago. Would like to use Eclipse for a small C++ program assigned as student homework. Set this up as an Eclipse C++ project.
I built the selected configuration as Debug and run it as Local C/C++ Application. All good. My C++ program runs and output appears in Console window exactly as I want it.
When I attempt Debug as Local C/C++ Application there is a message window Error with command: gdb --version. Cannot run program 'gdb': Unknown reason. So I am unable to launch my program in the Debug perspective and step-execute line by line, use breakpoints, examine variable assignments, etc.
When I attempt Profile as Local C/C++ Application, there is a message window Couldn't determine version of Valgrind. So I am unable to perform automated memory leak detection.
Do I need to complete my Eclipse installation in some additional way using Eclipse > Help > Install New Software option? Do I need to perform some additional installation(s) on my Mac that are outside of the Eclipse framework? I do not see what is missing here, as far as my software installations.
Any assistance, much appreciated..!
Properties for MyLittleProject, Tool Chain Editor
Current toolchain: MacOSX GCC
Current builder: Gnu Make Builder
Used tools
MacOS X C Linker
MacOS X C++ Linker
GCC Assembler
GCC Archiver
GCC C++ Compiler
GCC C Compiler
ABOUT ECLIPSE
Eclipse IDE for C/C++ Developers
Version: Luna Release (4.4.0)
Build id: 20140612-0600
INSTALLATION DETAILS>>INSTALLED SOFTWARE
Eclipse IDE for C/C++ Developers
EPP CPP Feature
C/C++ Autotools support
C/C++ Development Tools
C/C++ Common GDB Support
. . .
C/C++ GCC Cross Compiler Support
. . .
CDT Standalone Debugger Support
. . .
GDB Tracepoint Analysis
. . .
Valgrind Tools Integration
Profile Framework
Eclipse can find neither gdb nor valgrind on your computer. You have to install these manually. You see at INSTALLATION DETAILS>>INSTALLED SOFTWARE that the interfaces to these two programs are installed, yet the programs themselves are missing.
On Mac, you may want to use LLDB instead of gdb.
If you insist on using the two, you have to install them first. I am not familiar with MacOS, but maybe the following links prove to be usefull:
http://ntraft.com/installing-gdb-on-os-x-mavericks/
http://calvinx.com/2014/05/04/valgrind-on-mac-os-x-10-9-mavericks/
Amendment:
The valgrind plugin searches at a specific path for the binary. If it does not work, you need to add a symbolic link to the actual binary like so (from the offical documentation, note that there is a mistake which is corrected below):
ln -s $(which valgrind) /usr/bin/valgrind
I would like to create a HDF5 dataset from a fortran90 program compiled with intel fortran 2011 on Windows 7 using Visual Studio 2010
Can I use prebuilt binaries or how do I build new ones
I build from source, the available built binaries use the MS C/C++ compiler while I want to build with the Intel compiler, and they are built with Intel Fortran v12.x while I'm using v14.x. I won't say that you can't use the binaries, but I've had enough of a struggle in the past to persuade me to build my own.
I've also had struggles with trying to build them directly from VS and now use CMake. Your first step ought to be to install CMake and figure out how to use it. You don't need much knowledge of the tool and the effort will be repaid several times over. You can, for example, also use CMake to build Szip and Zlib, if you want them. An increasing amount of this sort of software is made available with CMake support so you won't necessarily only use it for HDF5. For example, I use CMake to build VTK for Windows too.
Once you've done that and generated the solution/project files with CMake you can load up the solution in VS and build ALL_BUILD. This generally works smoothly, though I have found that some projects need to have their linkages adjusted and sometimes I get spurious flags in the command-lines sent to the compilers. Then, running VS in administrator mode, you can build the pseudo-target INSTALL.
I see that HDF5 1.8.12 is now available, I'll download and build it, let you know how I get on.
Compiling and Linking
If you just want to use HDF5 include the line
USE, NON_INTRINSIC :: hdf5
at the appropriate place in your source file(s). Then, under Project Properties | Fortran | General | Additional Include Directories insert the path to the location of hdf5.mod. That should get you compiling.
To link, under Project | Properties | Linker | General | Additional Library Directories insert the path the location of the .lib files. Then, under Project | Properties | Linker | Input | Additional Dependencies insert hdf5_fortran.lib.
You should then be able to compile and link your program. If you want to use additional facilities, such as the HDF5 Table Interface, then use h5tb and figure out the linkages.
And consult the documentation. See, for example, ../HDF5-1.8.12/release_docs/USING_HDF5_VS.txt
I succeeded thanks to High Performance Mark:
Here was what I did (not sure that everything is necessary):
Download and install cmake
Download and install HDF5 [Windows (32-bit), Compilers: CMake VS 2010 C, C++, IVF 12, RWDI]
Set environment variable: HDF5_DIR=C:/Program Files/HDF_Group/HDF5/1.8.x/cmake/hdf5
Download HDF5 source
Make empty build folder
Run CMake(cmake-gui) from start menu
Set source (HDF5 source) and destination (empty build folder)
Configure
Set generator to Visual Studio 10
Specify native compilers [C:"", C++:"", Fortran: "<..>\ifort.exe"]
Check: BUILD_SHARED_LIBS and HDF5_BUILD_FORTRAN
Configure
Configure
Generate
Open <..>\build\HDF5.sln in Visual Studio 2010
build project ALL_BUILD
And finally
Create new project with a Fortran example
Linked the generated libs exactly as High Performance Mark describes
I hope some else can use the reciepe.
Thanks again
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b