C++ – How to tell C++ library path in Cygwin and MinGW

ccompiler-constructioncygwinmingw

I develop C++ programs using a Cygwin installation on top of Windows XP.

I also have MinGW installed, because I want to use it's version of g++, not the one that comes with Cygwin.

That part seems to be set up correctly. When I start a Cygwin session I see this:

$ which g++
/cygdrive/c/MinGW/bin/g++

This is correct, g++ is pointing to my MinGW install.

What I don't understand is when I write code that includes library code (for example, header files from the `Winsock/BerkleySockets API), how can I tell where the compiler is finding that header file?

For example, if I have #include "winsock.h" in my code, where does the compiler find that header file?

If I do a general search for winsock.h on my computer, I get this:

C:\MinGW\include
C:\cygwin\usr\include\w32api

Both have a copy of winsock.h (though the file sizes of these aren't exactly the same, so they can't be identical).

Thanks for the help.

I should also point out, I have the C:\MinGW\bin in my Windows PATH Environment Variable, as well as that same path configured in my/etc/profile file within Cygwin.

Best Answer

I'm guessing the g++ compiled for MingW has the same command line arguments as the standard g++. Check out the g++ manual page.

To add include paths to your compilation, use the -I flag.

g++ -I/include/path/here -I/another/include/path -o prog src.cpp

To add library paths to your linking, use the -L flag.

g++ -L/lib/path/here -L/another/lib/path -o prog src.cpp

The MingW site explains how the include file search works on MingW, and how to modify it.

The site also says that if you want to view the include file search while it happens during the compilation, pass the verbose flag (-v) to the compiler.

g++ -v -o prog src.cpp

Setting a bit

Use the bitwise OR operator (|) to set a bit.

number |= 1UL << n;

That will set the nth bit of number. n should be zero, if you want to set the 1st bit and so on upto n-1, if you want to set the nth bit.

Use 1ULL if number is wider than unsigned long; promotion of 1UL << n doesn't happen until after evaluating 1UL << n where it's undefined behaviour to shift by more than the width of a long. The same applies to all the rest of the examples.

Clearing a bit

Use the bitwise AND operator (&) to clear a bit.

number &= ~(1UL << n);

That will clear the nth bit of number. You must invert the bit string with the bitwise NOT operator (~), then AND it.

Toggling a bit

The XOR operator (^) can be used to toggle a bit.

number ^= 1UL << n;

That will toggle the nth bit of number.

Checking a bit

You didn't ask for this, but I might as well add it.

To check a bit, shift the number n to the right, then bitwise AND it:

bit = (number >> n) & 1U;

That will put the value of the nth bit of number into the variable bit.

Changing the nth bit to x

Setting the nth bit to either 1 or 0 can be achieved with the following on a 2's complement C++ implementation:

number ^= (-x ^ number) & (1UL << n);

Bit n will be set if x is 1, and cleared if x is 0. If x has some other value, you get garbage. x = !!x will booleanize it to 0 or 1.

To make this independent of 2's complement negation behaviour (where -1 has all bits set, unlike on a 1's complement or sign/magnitude C++ implementation), use unsigned negation.

number ^= (-(unsigned long)x ^ number) & (1UL << n);

unsigned long newbit = !!x;    // Also booleanize to force 0 or 1
number ^= (-newbit ^ number) & (1UL << n);

It's generally a good idea to use unsigned types for portable bit manipulation.

number = (number & ~(1UL << n)) | (x << n);

(number & ~(1UL << n)) will clear the nth bit and (x << n) will set the nth bit to x.

It's also generally a good idea to not to copy/paste code in general and so many people use preprocessor macros (like the community wiki answer further down) or some sort of encapsulation.

Windows – the difference between Cygwin and MinGW

As a simplification, it's like this:

Compile something in Cygwin and you are compiling it for Cygwin.
Compile something in MinGW and you are compiling it for Windows.

About Cygwin

Cygwin is a compatibility layer that makes it easy to port simple Unix-based applications to Windows, by emulating many of the basic interfaces that Unix-based operating systems provide, such as pipes, Unix-style file and directory access, and so on as documented by the POSIX standards. If you have existing source code that uses these interfaces, you may be able to compile it for use with Cygwin after making very few or even no changes, greatly simplifying the process of porting simple IO based Unix code for use on Windows.

When you distribute your software, the recipient will need to run it along with the Cygwin run-time environment (provided by the file cygwin1.dll). You may distribute this with your software, but your software will have to comply with its open source license. Even just linking your software with it, but distributing the dll separately, can still impose license restrictions on your code.

About MinGW

MinGW aims to simply be a port of GNU's development tools for Windows. It does not attempt to emulate or provide comprehensive compatibility with Unix, other that to provide a version of the GNU Compiler Collection, GNU Binutils and GNU Debugger that can be used natively in Windows. It also includes header files allowing the use of Windows' native API in your code.

As a result your application needs to specifically be programmed for Windows, using the Windows API, which may mean significant alteration if it was created to rely on being run in a standard Unix environment and use Unix-specific features. By default, code compiled in MinGW's GCC will compile to a native Windows X86 target, including .exe and .dll files, though you could also cross-compile with the right settings, since you are basically using the GNU compiler tools suite.

MinGW is a free and open source alternative to using the Microsoft Visual C++ compiler and its associated linking/make tools on Windows. It may be possible in some cases to use MinGW to compile something that was intended for compiling with Microsoft Visual C++ without too many modifications.

Even though MingW includes some header files and interface code allowing your code to interact with the Windows API, as with the regular standard libraries this doesn't impose licensing restrictions on software you have created.

Other considerations

For any non-trivial software application, such as one that uses a graphical interface, multimedia or accesses devices on the system, you leave the boundary of what Cygwin can do for you and further work will be needed to make your code cross-platform. But, this task can be simplified by using cross-platform toolkits or frameworks that allow coding once and having your code compile successfully for any platform. If you use such a framework from the start, you can not only reduce your headaches when it comes time to port to another platform but you can use the same graphical widgets - windows, menus and controls - across all platforms if you're writing a GUI app, and have them appear native to the user.

For instance, the open source Qt framework is a popular and comprehensive cross-platform development framework, allowing the building of graphical applications that work across operating systems including windows. There are other such frameworks too. In addition to the large frameworks there are thousands of more specialized software libraries in existence which support multiple platforms allowing you to worry less about writing different code for different platforms.

When you are developing cross-platform software from the start, you would not normally have any reason to use Cygwin. When compiled on Windows, you would usually aim to make your code able to be compiled with either MingW or Microsoft Visual C/C++, or both. When compiling on Linux/*nix, you'd most often compile it with the GNU compilers and tools directly.