I'm starting a new job. I'm a windows guy that has been working in the Microsoft stack for decades. The new job calls for work to be done on a Mac, and I'll be working in straight C code. It's interesting, and I vaguely remember using it a tiny amount in the mid-90s. But I'm running into a problem. When I try to compile the code ("make" command on the command line tool) it throws an error...
The codebase I'm learning is trying to use the *strdup(const char *__s1) function/method as defined in the string.h include file. When I look at that header, I see where it would be defined, but there's a preprocessor if-block around it that looks like...
#if __DARWIN_C_LEVEL >= 200112L
Looking around for that __DARWIN_C_LEVEL variable online... I see people asking what it is, but I haven't seen anything about what to do if your value is too low. I tried looking for a way to alter a config file or something on my machine so that value would just be high enough, but I can't find that. Is there something I need to update so that the code does what I want?
As an additional note, the only other guy at work that does anything in this code base works on a straight linux machine and edits the code with Vi. He's obviously an expert in the code base and his environment, but doesn't know how to help with trying to get this running on MacOS.
Any help would be appreciated.
Edit 9 November 2020
I'm beginning to believe I don't actually have the latest version of XCode if that would explain the issue. I haven't gotten a response, but I'm asking about help with that piece here at work.
I'm also trying suggestions. When I try the option for std=gnu11...
make -std=gnu11
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- =
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- g
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- u
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- 1
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- 1
If I remove the equal sign, it seems to like it better but still has errors...
make -std gnu11
[...]
No implicit rule found for 'gnu11'.
Finished prerequisites of target file 'gnu11'.
Must remake target 'gnu11'.
make: *** No rule to make target `gnu11'. Stop.
Related
In an attempt to add the include paths to Syntastic (3.6.0-106; Vim 7.3), to stop it from giving a fatal error at the first include it can't find, I tried creating a .syntastic_c_config file. There's not a lot of information on how this is supposed to work, but there are references out there and I followed their example:
-I/path/to/include
-I/you/get/the/idea
-L/some/library
-lfoo
-lbar
-DHAVE_SOME_FLAG
-pedantic
-Wall
-std=c99
That is, one compiler argument per line.
This has had the effect of removing virtually all error checking, unless I force it with :SynasticCheck -- at which point, it seems to work a little bit better, but not exactly how I'd expect. However, either way, if I :echo g:syntastic_c_config_file (or any other option that I'm expecting to be set), Vim just gives me an undefined variable warning.
I'm clearly doing something fundamentally wrong, but I'm not really sure what!
This is an old post, but I stumbled upon here searching for an answer to the same problem. Looks like Syntastic has changed quite a bit. Documentation listed above by OP is not valid anymore. Current (as of 18 July 2020) documentation is at: https://github.com/vim-syntastic/syntastic/blob/master/doc/syntastic-checkers.txt
To add include paths to 'gcc' checker, you would need to create a file with your include dirs, one per line, preceded by '-I'. For example, in /home/user/.syntastic_c_config_file add:
-I/usr/include/glib-2.0/include
-I/usr/include/boost
Then in your {vimrc} file (usually, ~/.vimrc), add one line:
let g:syntastic_c_config_file='/home/user/.syntastic_c_config_file'
Syntastic has become more powerful now and contains many options in the above linked documentation.
It turns out that Syntastic will source the configuration file without explicitly setting the respective variable. Moreover, the contents of the configuration file are not passed into any syntastic_c_* variables, but nonetheless passed into the call to gcc. Syntastic is also clever enough to backtrace to look for the configuration file (e.g., it will go up levels until it finds it, so you can keep the .syntastic_c_config in your project root).
As to why it was failing, the debug log was showing that my compiler was ignoring the library flags (-L/some/path and -lfoo) and that was blocking Syntastic from any further syntax checking. Removing those lines from my config file solved the problem.
I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.
Im stuck on compiling the tsr.asm code provided in the book rootkit arsenal.
I installed open watcom on a XP maschine and the first asm listing was compiled well.
When compiling, it throws the error: "multiple starting address found" (nothing found on google). Can anyone confirm that this code is compilable, and how?
Im thankful for any suggestions.
When you're writing some code, there is a particular address where the execution is to begin (the main function in C for example), but in your code there are more than one starting address, and it crashes when compiling. But without seeing the code I can't tell you more.
Sorry for the late answer, but I was searching for an answer to this and just figured it out - hopefully it'll help someone else Googling around for an answer.
Since you're using OpenWatcom (I'm using version 1.9), I'll assume that you have tsr.asm in its own OpenWatcom 16-bit DOS COM project. In the IDE, go to Targets -> Target Options -> Linker Switches. In the window that appears, select "2. Import, Export and Library Switches" from the drop-down at the top and remove the cstart_t entry under "Library files(,): [libf]".
Recompile, and your TSR COM file should be generated.
I have looked through both the CodeBlocks and MinGW FAQ and wiki to no avail. As stated above I am a noob.
I want CodeBlocks to act like a Unix compiler in that it overwrites a single output file every time it compiles unless told to do otherwise.
In Unix:
[cc example.c] -> [a.out], [cc example2.c] -> [a.out]. If I want to save the output file from being overwritten i just [cc -o newname example3.c] - [newname.out].
If this is possible with CodeBlocks/MinGW on XP I'd like to know how to do it. If not I would appreciate recommendations for another GUI compiler/IDE that could. Any help is appreciated. Thank you.
I want CodeBlocks to act like a Unix
compiler in that it overwrites..
First of all, C::B isn't a compiler -- it's an IDE. Saying you want C::B to act like a compiler makes no more sense then saying you want vim, emacs, or visual studio to 'act' like a compiler.
Second, you change the name of the final executable by right-clicking a project in your workspace. Goto properties->Build targets tab->select which build target you want to change. On the right side of this you'll see Output filename. Enter the executable filename the linker should output here. Alternatively, you can just navigate to the location of your existing executable and just rename it to something else.
And thirdly, chances are you're not even going to be checking back on this site so I'm probably just wasting my time giving an answer to your post.
I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv