I downloaded the latest Boost Jam binary from SourceForge and I'm using the command:
bjam toolset=gcc --build-type=complete stage
I've installed Cygwin along with the GCC compiler. While the command produces a stage/lib directory, I cannot find the thread library that I'm using in Linux. Boost Jam takes a while to run, so there could have been errors along the way. Can anyone guess as to why I don't have the thread library? Is there a specific command I can run in an attempt to only build the thread library? Thanks!
You most definitely need to check for, and provide the error messages. You can also try passing either threadapi=pthread or threadapi=win32 to Boost.Build invocation.
In general, using the GNU/Kernel32.dll operating system, sometimes referred to as Cygwin, is risky business. Will using the native port of gcc, from mingw, be sufficient for you?
Related
TL:DR;
Can I write GUI programs on Win 10 (64) using Rust without installing the full MinGW toolchain (nor the MS equivalent)?
Supplementary questions:
- If not, should I just go ahead and install MinGW?
- Does anything GNUish in Windows 10 Anniversary Update change any of this?
Longer version
I saw that Rust is the most loved programming language hereabouts so 15 minutes ago...
I read
No additional software installation is necessary for basic use of the GNU build.
Rust's support for the GNU ABI is more mature, and is recommended for typical uses.
So I downloaded Windows (GNU ABI †) (.msi) 64-bit to my PC running Windows 10.
TUI
I read some basic intro and used rustc to compile a Hello World! and ran it OK. I then read about cargo and reorganised buit and ran the same code using that.
GUI
I then searched for Rust GUI and found Kiss_UI
a simple UI tookit for Rust
So I did a cargo new Hello_GUI --bin and added
[dependencies.kiss-ui]
git = "https://github.com/cybergeek94/kiss-ui"
to Cargo.toml
I cut and pasted a simple example from that website into main.rs
I then ran cargo run --verbose. It did
Updating git repository `https://github.com/cybergeek94/kiss-ui`
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading iup-sys v0.0.3
Downloading libc v0.2.14
Downloading libc v0.1.12
Compiling libc v0.1.12
...
warning: crate `Hello_GUI` should have a snake case name such as `hello_gui`, #[warn(non_snake_case)] on by default
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" ...
note: ld: cannot find -liup
error: aborting due to previous error
So I learned two things
I need to use snake case.
GUI programming is not "basic use".
I have no complaints about either of these points but could use a clue or two about the second:
Assuming I want to write a GUI equivalent of Hello World in a simple way, what are my main options now?
According to its documentation, kiss-UI depends on the IUP library.
The error from gcc (can't find -liup) suggests that you don't have IUP installed. You may be able to install it and have things work; it depends on whether the IUP bindings used by kiss-UI can cope with windows.
Some other GUI libraries can be found at awesome-rust. There are bindings to libraries like Qt and Gtk. If you know the windows API, you could also check out the winapi crate.
If you want to avoid messing with linking and stuff, you could try using a pure rust library like conrod, which should 'just work' on windows.
To answer your more broad questions:
See the footnote on the downloads page. The MSVC version of rust depends on MSVC being installed. The GNU/MinGW build is standalone.
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 am using msys2 Mingw (gcc 4.8.2 for i686 32-bit) for building Ghostscript 9.10. After running make, gs.exe was created successfully. Followed by that I ran "make so" for creating libgs library. Libgs.so, Libgs.so.9.10 were created which are of the same file size. But I found both of them to be PE executables. After renaming extension to .exe, they produced the same output as done by gs.exe. What I require is libgs.dll, libgs.a to be created, but instead "make so" creates libgs.so which is in fact a PE executable. I also tried using patch found on site:https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ghostscript/mingw-build.patch, but still the output remains the same. Has anyone been successful in this? Kindly help me.
I presume if you follow the steps taken in the build script connected to the patch you linked, everything will work out fine. I think most of it is just to make it use the "system"'s 3rd party libraries instead of those in the GS source. I'd guess running the configure command would do.
Alternatively, you could just download the MSYS2 base system from here, and do a pacman -Syu mingw-w64-i686-ghostscript. It should download and install the binary package without you having to build it yourself.
If you really want to build it yourself, download the PKGBUILD and patch, and run makepkg from the aforementioned MSYS2 shell and have that build it for you.
Have just completed testing of gs 9.15 built executables using the a patch
MINGW-packages-master.zip from https://github.com/Alexpux/MINGW-packages
Without implementing the zlib patch and PKGBUILD and using a MINGW 4.7.3 32/64
without by ghostscript used libs installed.
They did not work as is while using msys1 pathe'd up ahead of Windoze.
I simply edited the the MINGW Build and 32/64 bit type in makefile in
and set them to =1 there. and as i built without GTK defined in ./configure
SOC_LOADER_PLAIN manually to gs.c
Check the makefile after ./configure ahead of make or make so though , , .
All went well except for the COMPILE_INITS
mkromfs build that failed so I had to set that to =0 and build without that
feature. For me personally preferred as one can patch the gs fonts and libs
much easier.
The builds run as charm with full cpu optimisers implemented
only disabling gcse and guess-branch-probability, easily outperforming
the binaries provided by http://www.ghostscript.com/ by all means.
HPC !
Upon finishing a COBOL program, how do I compile it into an executable file that may be run on other PCs? I'm using OpenCOBOL via cygwin.
Check out this getting started page from the user manual for OpenCOBOL:
But in case the link is broken, just do this:
$ cobc -x hello.cob
$ ./hello
cobc is the compiler. hello.cob is the source file. The output is simply the file hello which can be run by calling ./hello. The -x option is necessary to build an executable.
However, with all compiled programs, it is compiled for the machine is was built on. It will work on machine with similar architectures, but you don't true cross-platform ability unless you're using an interpreted language like Python or Java.
If you compile with Cygwin, the target computers also need Cygwin, or in particular the cygwin dynamic libraries along with the OpenCOBOL runtimes.
Many times, you can also compile under MinGW, which lessens the dependencies, but also lessens the available POSIX features.
Easiest path, install OpenCOBOL and Cygwin on the target machines, and you'll be good to go, otherwise you'll need to produce release packages with all the dependencies and instructions for PATH settings.
the basic idea was, I wanted to generate the call graph in text format for several c files. After googling around for long time, i found cflow, which can deliver everything I want, but it is only runable in Linux or else. Then I began to search how to compile the cflow source files on the web to a exe file. I found MinGW which should be able to do the cross-platform compilation.
After installing the MinGW and the MSYS and running the usual commands "./configure; make; make install", I simply got an error that "mkdir" was not found. Actually. Actually I was wondering whether this is the correct way to compile the whole package.
Does anyone has an idea how I can build the cflow.exe correctly in Windows? If there is a tutorial or something like this, I will be very thankful.
Song
Solution
Please try this Github repository "MinGW + MSYS build of GNU cflow 1.4" (For Windows).
https://github.com/noahp/cflow-mingw
It contains already compiled "cflow.exe",and an instruction about how to build cflow using mingw and msys.
Test
System Environment:Win 8.1 (x64)
1.I tested the "cflow.exe" downloaded from the github repository , and amazingly it worked!
2.I followed the mingw compiling instruction,and it successfully compiled "cflow 1.5".
Command:
bash configure
make
I was able to do that today. I'm using cygwin, after installing gcc, binutils, make and after downloading the gnu cflow.tar.gz, it was as easy as ./configure ; make ; make install.