I have missing header files like malloc.h and conio.h in my MAC.. how do I install it?
gcc linkedlistmenu.c
linkedlistmenu.c:2:19: fatal error: malloc.h: No such file or directory
First off, malloc.h is deprecated (and not available on your system). Instead, you should be using stdlib.h. Furthermore, conio.h is an implementation specific header - and in this case, it is Windows and MS-DOS specific. It is not available on MacOS. Both of these are non-standard headers, and therefore are not preferred due to issues with portability. ncurses (which should already be available on MacOS) provides similar functionality to conio.h; see if that has what you're looking for.
However, your best shot if you really need these header files is to install a virtualization program such as VirtualBox, install Windows, and work from there.
Related
So I've been reading online but I'm still very confused. I understand that there are different tools in the Linux-on-Windows world: Msys, Msys2, Cygwin, Mingw and Mingw-64.
Here is what I think I know, and please correct me if I'm wrong:
Mingw aims to simply be a port of the GCC programs to Windows. It creates native Windows binaries and that's it.
Mingw-64 is just a more recent and better supported version of Mingw that also supports Windows 64 bit.
Cygwin, while also including Mingw (?) to support GCC on Windows, provides a POSIX compatibility layer through a DLL that all programs are linked to by default.
MSYS is a fork of Cygwin, but it drops some of the POSIX compatibility efforts. Instead it mostly aims to allow creating native Windows program. But - they will still be dependent on a MSYS DLL being present.
MSYS2 is just a more recent and active version of the less active MSYS.
Is this all true? If it is, here is what I want to validate:
Essentially, I think all I should need for my development is Mingw in order to use GCC to build native Windows applications. I don't need a POSIX layer, and I don't want my program to depend on any DLL apart from the ones that are present on Windows systems anyway. As far as I understand, this is what Mingw offers.
However, somehow I managed to install MSYS (or MSYS2? I'm not sure anymore) on my system. The tutorial I was following early on suggested doing so.
Since it seems MSYS(2) includes Mingw under C:\msys64\mingw64, I just use the Mingw binaries directly from the Windows CMD without going through the MSYS(2) shell program. For example, I just added C:\msys64\mingw64\bin to the PATH and I run gcc from the Windows CMD directly to compile my project.
Is this a valid way to use Mingw? Or am I expected to run into problems?
Does this approach create pure Windows native binaries which should never depend on any MSYS(2)-related DLL?
Is it true that the MSYS(2)-related functionality and dependencies only come into play if I launch the Mingw programs (such as GCC) through the msys2.exe shell program? And so if I want to avoid any MSYS(2) or Cygwin related stuff, and simply use pure Mingw GCC, is it an okay approach to just launch GCC directly under the Mingw directory as described earlier?
Update: I have now checked using Dependency Walker, and running C:\msys64\mingw64\bin\gcc from the MSYS2 shell still creates an .exe with no special dependencies (which is good). So what is this msys-2.0.dll that the MSYS2 docs speak of? And how is using MSYS2 to compile C different than just using Mingw?
You're mostly right about what these projects are. MSYS2 does provide an evironment for POSIX programs like Bash, GNU Make, and other utilities, but it also provides a package manager named pacman that you can use to install lots of other things. In fact, you can use pacman to install a mingw-w64 toolchain.
MSYS2 provides two mingw-w64 toolchains actually: you get a choice of an i686 (32-bit) toolchain which makes native Windows binaries that can run on any Windows computer, or an x86_64 (64-bit) toolchain that makes native Windows binaries that only work on 64-bit Windows. You can install both of these at the same time.
You say "I don't need a POSIX layer", but you might find it useful to be able to write Bash scripts or use POSIX programs provided by MSYS2 like GNU Make when building your native Windows software. This is especially useful if you want to someday build your software on Linux or macOS: it's possible to write a simple Makefile or shell script that works on those platforms and also MSYS2.
Yes, it's valid to use the binaries from C:\msys64\mingw64\bin directly if you want to.
Yes, the mingw-w64 toolchain creates native Windows binaries regardless of which shell you happen to run it from.
No. Whether you start MSYS2 via msys2.exe, mingw32.exe, or mingw64.exe, you get a Bash shell with various Linux utilities available like ls, grep, make, and tar. The shell and those utilities use the POSIX emulation provided by msys-2.0.dll. The main difference between those MSYS2 launchers is what gets added to your PATH, so you might want to run echo $PATH and env in each of those environments and compare the results.
I'd strongly recommend using MSYS2 instead of MSYS and mingw.org . Pretend those latter two don't even exist. Being under active development the newer projects are better in every way.
MSYS2's package manager can deliver toolchains for the following target systems:
Standalone Win32 (i686)
Standalone Win64 (x86_64)
MSYS2 i686
MSYS2 x86_64
The former two cases can be invoked from any shell you like. You may need to set up paths if not using the launch script provided by MSYS2. They produce native Windows executables. Using the default switches to GCC there will be some dependencies, such as libgcc_s*.dll . Doing a static build with -static will produce an executable with no dependencies other than Windows DLLs.
In the latter two cases, the binary will depend on the MSYS2 DLL, and other things, but this provides support for a range of POSIX functionality.
[~ MSYS]$ ls /usr/include
_ansi.h cursesp.h glob.h net strings.h
_newlib_version.h cursesw.h gnumake.h netdb.h symcat.h
_syslist.h cursslk.h grp.h netinet sys
a.out.h cygwin icmp.h newlib.h sysexits.h
acl devctl.h ieeefp.h nl_types.h syslog.h
aio.h diagnostics.h ifaddrs.h panel.h tar.h
alloca.h dirent.h inttypes.h paths.h term.h
alpm.h dis-asm.h io.h plugin-api.h term_entry.h
alpm_list.h dlfcn.h langinfo.h poll.h termcap.h
ansidecl.h elf.h lastlog.h process.h termio.h
ar.h endian.h libfdt.h pthread.h termios.h
argz.h envlock.h libfdt_env.h pty.h tgmath.h
arpa envz.h libgen.h pwd.h threads.h
asm err.h limits.h reent.h tic.h
assert.h errno.h locale.h regdef.h time.h
attr error.h machine regex.h tzfile.h
bfd.h eti.h magic.h resolv.h ucontext.h
bfd_stdint.h etip.h malloc.h sched.h unctrl.h
bfdlink.h fastmath.h mapi.h search.h unistd.h
bits fcntl.h math.h semaphore.h utime.h
byteswap.h fdt.h memory.h setjmp.h utmp.h
complex.h features.h menu.h signal.h utmpx.h
cpio.h fenv.h mntent.h spawn.h w32api
ctf.h FlexLexer.h monetary.h ssp wait.h
ctf-api.h fnmatch.h mqueue.h stdatomic.h wchar.h
ctype.h form.h nc_tparm.h stdint.h wctype.h
curses.h fts.h ncurses stdio.h winpty
cursesapp.h ftw.h ncurses.h stdio_ext.h wordexp.h
cursesf.h gawkapi.h ncurses_dll.h stdlib.h xlocale.h
cursesm.h getopt.h ncursesw string.h
[~ MSYS]$
[~ MSYS]$
[~ MSYS]$ ls /usr/include/sys
_default_fcntl.h acl.h fcntl.h mman.h quota.h signal.h stdio.h termio.h ttychars.h utsname.h
_intsup.h cdefs.h features.h mount.h random.h signalfd.h strace.h termios.h types.h vfs.h
_pthreadtypes.h config.h file.h msg.h reent.h smallprint.h string.h time.h ucontext.h wait.h
_sigset.h custom_file.h iconvnls.h mtio.h resource.h socket.h sysinfo.h timeb.h uio.h xattr.h
_stdint.h cygwin.h ioctl.h param.h sched.h soundcard.h syslimits.h timerfd.h un.h
_timespec.h dir.h ipc.h poll.h select.h stat.h syslog.h times.h unistd.h
_timeval.h dirent.h kd.h procfs.h sem.h statfs.h sysmacros.h timespec.h utime.h
_types.h errno.h lock.h queue.h shm.h statvfs.h sysproto.h tree.h utmp.h
Cygwin is a competing product also providing POSIX functions and depending on a Cygwin DLL. The MSYS2 target is a fork of Cygwin.
I recently switched my PC at work from Ubuntu to Arch Linux.
And I am now getting the following error (I am using stack to build my project):
setup-Simple-Cabal-1.22.4.0-ghc-7.10.2: Missing dependency on a
foreign
library:
* Missing C library: HSrts-ghc7.10.2
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
As far as I understand it, the difference in Linux Distribution should not cause any issue.
Things I have tried:
-add the path where the library is with --extra-lib-dirs
-make sure that the version of stack/ghc are the same acrose both systems
-tried unsucesfully to find a relevant difference between the 2 systems
(gcc version was different but didn't change anything)
I have a docker container based on ubutu where it builds without an issue.
The only thing I can think of is that this library gets handled differently from some random C-library since it contains the Haskell-Runtime. But I have no idea what this difference would be. Or how a differnent handling would cause an issue on my Arch System.
Here my .cabal file (the folder also contains the whole project):
https://github.com/opencog/atomspace/blob/master/tests/haskell/libExecutionOutputTest/opencoglib.cabal
Okay i figured out a workaround, instead of specifiyc the library in the .cabal file:
...
extra-libraries: HSrts-ghc7.10.2
...
you add it to your stack.yaml file:
...
ghc-options:
package-name: -lHSrts-ghc7.10.2
...
If you also have a exectuable defined in your .cabal file this will break the executable, since the library is not only included in the library. And including the runtime library in an executable results in an instant segementation fault.
I'm writing an application that uses ncurses.
In Debian and Ubuntu, I have the choice between these packages:
libncurses5-dev
libncursesw5-dev
The w version includes wide-char support, which is what I want.
However, if I only install libndursesw5-dev, I get an error message when I compile with -lncurses or -lncursesw where it tells me it can't find curses.h or ncurses.h.
Installing both libncurses5-dev and libncursesw5-dev and using -lncursesw works, but I'm not sure if that is the proper way or just coincidentially seems to work. Using -lncurses will bring in a non-wide-char library.
For reference, on Mac OS X 10.11, -lncurses works (with wide-char support) and -lncursesw doesn't work at all.
Debian installs the two headers
/usr/include/curses.h
/usr/include/ncursesw/curses.h
as a workaround for compatibility. The latter is "mostly" compatible, but only at compile-time. For instance the WINDOW structure is larger in the latter. The first (/usr/include/curses.h) is "standard", but preceded the ncursesw library by several years. Because some of the platforms to which ncurses was ported do not use ncurses as the system curses library (e.g., Solaris), provision was made for putting ncurses' header in a subdirectory to avoid overwriting (or conflicting with) the system's standard curses.h (see the ncurses FAQ Is the ncurses library compatible with my system?).
Since Debian started with ncurses as the system curses library, its packagers chose to use the same workaround to avoid conflict between ncurses and ncursesw. Packagers on some other systems could choose to put both in subdirectories and make a link in their packaging scripts like
/usr/include/curses -> /usr/include/curses/ncurses.h
I recall that Cygwin did something like that, and omitted the link for unctrl.h (a bug, because it too is a standard header).
For OSX, the system provides only ncurses (not ncursesw), and most people using ncursesw do this via something like MacPorts, which installs the ncursesw header (which works well enough if the application defines _XOPEN_SOURCE_EXTENDED when compiling for ncursesw,
since the declaration of WINDOW is ifdef'd to allow either library to be supported). The Debian packagers were more cautious and chose to keep the headers separate.
I'm using a third-party library which includes malloc_np.h. From what I found over internet, this means that the code was supposed to compile under FreeBSD, although simply changing the include to malloc.h made it compilable under Linux (Ubuntu 13.10).
Now I'm writing a CMake script for this library to generate appropriate make files (including NMake makefiles for MSVC 2010).
What is the best way to achieve portability in such a scenario?
My current solution is to test for:
${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD"
in the CMake script. Depending on the result I issue a
add_definitions (-DINCLUDE_MALLOC_H="#include <malloc[_np].h>")
command and use this macro in the source file instead of #include <malloc_np.h>.
Is this a good practice?
Generate time
Use CheckIncludeFile* modules:
include(CheckIncludeFileCXX)
check_include_file_cxx("malloc.h" have_malloc)
if(have_malloc)
add_definitions(-DINCLUDE_MALLOC_H)
endif()
Compile time
Use boost.predef library to detect os specific features
#include <stdio.h>
int main(void)
{
printf ("Programming is fun");
return 0;
}
When I use the cc command in terminal to compile the above program it returns
fatal error: 'stdio.h' file not found`
I compiled this exact code on ubuntu where it created an a.out-file, which sadly did not run either. While I'm not sure why either happens at least no error was produced on ubuntu.
For recent macOS, people would miss C headers after system update.
cd /Library/Developer/CommandLineTools/Packages
open macOS_SDK_headers_for_macOS_xx.pgk
I guess this is another Apple's bug.
You don't specify the platform you're on...
If stdio.h is not found, it usually mean you don't have the necessary header files on your system (usually in /usr/include/).
Your compiler might be working fine, but it looks like the C-Library headers are not installed.
Depending on your platform, you'll have to install them.
It's a bit weird that you have a working compiler without C library headers.
You may want to reinstall your compiler, or search for a package which contains the headers for the C library.
If you're on OS X, (re)install Xcode as well as the command line tools.
If you're on Linux, use your package manager to install the development package for C (e.g. libc6-dev on Debian).
Before you go reinstalling your compiler you might want to check your include paths. As you don't specify your platform I can only provide general information but this is similar on many platforms.
Using cc you need to set them in the environment. Try typing 'env' to see your current settings. There needs to be a line that sets a variable 'include' with the full path to the location of your studio.h.
You can also set the include path in the make file or, if using an IDE, in the project settings.
There is something wrong with how your compiler is configured.