I am trying to build an automated build system. It took me a little while to change a working wii generic makefile to a working win32 (using mingw32) makefile.
my make is here http://pastie.org/319482
The weird effect is, if i remove the a preceding the paths in ABS_INCL (line 31) the build doesnt work and complains about missing a header which is specified by the first path. Why is it doing this? i cant track the problem down.
The next issue is when i dropped in code that requires libcurl, i can still compile but no longer link as expected. I added curl to my libs (line 47) and the path (line 53) and it looks like i am including it right and the lib is in the right order (i tried to touch as little as possible while converting wii to win32) and i cant see the problem. Does anyone know why this is happening?
here is simple source to test with
#include <stdio.h>
void main2();
int main( int argc, const char* argv[])
{
int a=0;
printf("hey");
main2();
return 0;
}
#include <curl/curl.h>
void main2()
{
CURL *curl = curl_easy_init();
curl_easy_cleanup(curl);
}
You're not getting a lot of answers here - I'm going to go out on a limb and tell you it's because of your really badly written title. I've read it maybe 20 times as it scrolled down the home page and I still don't really get it. There is the obvious spelling mistake, and I want to go in and fix that but then there is the whole weirdness with the "-l" and "-L" and I can't tell where you are going with that.
So, most people will look at that and just blank out and move on. Assuming they get past that, you failed to add the useful information contained within your makefile to the question and so you've gotta go off and read it on the other site.
Finally, as one more hurdle, your makefile is too long to easily read and absorb. So assuming someone like me who is really kind of determined goes and reads it, it's too difficult to tell where the problem could lie within that. You need to edit it down to probably ten lines or less, and then assuming you haven't been able to figure out the problem, you could then post just those few lines that showed the problem in your question and then with a decent title and some good descriptive text, you'll probably get your answer.
I'm guessing the answer to your question isn't even that hard, you've successfully managed to obfuscate it to the point that most people wont even bother.
Related
I like my code to look clean. I try to follow recommendations, etc. It helps keep everything tidy, conforming, and decent.
But sometimes, you need to defeat the linter because it has a bug, or it just doesn't understand what you intend.
In this case, I have the following code:
fmt.Println("Enter values between %00 and %0f.")
VSCode complains with:
fmt.Println call has possible formatting directive %0f (printf)
That's a reasonable thing for it to think, and I thank it very much for warning me of a possible mistake I might have made... but in this specific case, I really do want it to print %0f as-is. I really, really know what I'm doing here.
Normally, I might do something like this:
//lint:ignore printf No, really, this is what I want
fmt.Println("Enter values between %00 and %0f.")
But VSCode still gives the yellow wavy line and completely ignores the lint:ignore directive.
I must work around this annoyance with:
fmt.Printf("Enter values between %%00 and %%0f.\n")
But I'd prefer to use the original syntax, as the intent is clearer, and the line matches what I've written everywhere else in this part of the overall code.
So, how do I put my foot down and freaking tell the cursed program to stop placing its errant yellow wavy line because, dammit, I really do know what the I'm doing? It is not only distracting, but it wastes my time as I keep looking over the 'linting error' only to see it's not an issue.
Edit
Some additional information might be useful.
In my desire to keep things as uncomplicated as reasonably possible, I use the 'Go' extension, with no changes to the linter it defaults to using.
Examining these settings, it looks like it's using staticcheck. And, indeed, I see that in the local bin folder.
But staticcheck doesn't care. It doesn't complain at all about the fmt.Println() I wrote, even if I don't have a //lint:ignore line above it, when I run it explicitly.
I have a rather weird question but I don't really know how to put it or where to start looking from.
My question is not about "embedding" a text file (we already have at compile time) - that is too obvious.
My question is if (and how) I could let's say "package" an existing (created by C) binary with a text file and generate a new... working binary with access to that file.
I'm a Mac user. I know that could work with an .app package and all that. But that's still not what I want. I want to be able to "tweak" an existing binary, add some (accessible - how?) additional text data to it, and the binary remaining absolutely functional.
Is that even possible?
P.S. The only serious tool I've looked into is bsdiff and bspatch but I'm not really sure it's what I'm looking for.
You can definitely do this, but the exact procedure is going to be different for every platform, with a few commonalities. Your tool of choice here is probably going to be llvm_objcopy.
At a high level, you will create a special segment or section in the binary (or both as in the case of MachO) containing the data you want, and then you'll have to parse your own executable to retrieve it. Since you said you're on a Mac, we can start there as an example.
Create the dumbest possible test program as a starting point:
test.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("I'm a binary!\n");
return 0;
}
Compile and run it:
prompt$ clang -o test test.c
prompt$ ./test
I'm a binary
Now create a text file hello.txt and put some text in it:
Hello world!
You can embed this into the MachO file with llvm-objcopy
llvm-objcopy --add-section __MAGIC,__magic_section=hello.txt test test
Then check that it still runs:
prompt$ ./test
I'm a binary!
You can verify that the section has been added using otool -l, you can also run strings on the binary, and you should see your text:
prompt$ strings ./test
I'm a binary!
Hello world!
Now you have to be able to retrieve this data. If you were compiling everything in a priori, it would be easy since the linker would make symbols for you marking the start and end of the __magic_section section that you added.
Since you specifically said this has to be an a posteriori step, you're going to have to actually self-parse the MachO file to look up the __magic_section section in the __MAGIC segment that you added. You can find a few different references for parsing MachO files, but you probably also want to make use of built in dyld functionality. See Apple's Reference on dyld utility calls that can for example give you the Mach header for the running process. Linux has similar functionality by way of dl_iterate_phdr.
Once you know where the section is in your original binary, you can retrieve the text.
To repeat all of this on Linux, you will do pretty much the same thing, but you'll be working with the ELF file format instead of MachO. The same principles would apply though.
As a side note: this is exactly how code signing works on MacOS. A signature is generated and placed into a dedicated "signature" section in the binary to be read by the system on launch.
I have recently gotten into programming and decided to learn C++. I took advantage of the sale on Udemy and bought three courses there, one for beginners on C++, one for game-making and one for Blender.
I started doing the course for beginners, the lecturer said that he would use Code::Blocks but that any other IDE would be fine so I downloaded Visual Studio 2017 because that's what the game-making course used. But when I do exactly as the lecturer says (and writes), the code won't compile correctly.
Here is an example:
What the lecturer wrote and got to work on his computer
#include <iostream>
using namespace std;
main()
{
cout << "Hello world! :-)";
}
What I figured out would work after some googling
#include <pch.h>
#include <iostream>
using std::cout;
int main()
{
cout << "Hello world! :-)";
}
And my question to those who are experienced is: What is the difference between Code::Blocks and Visual Studio 2017? What is different in that case? Will I even be able to use this course to learn?
Thanks in advance!
edit: edited in a missing # in the lecturer's code
#include <pch.h>:
See Gabriel's answer.
include <iostream> vs #include <iostream>:
The former is plain wrong. It has to be #include with the #.
using namespace std; vs using std::cout;:
While neither is particularly good practice, both should do the same thing here. If you write neither of them, you will have to write std::cout << ... instead of only cout << ... - that seems annoying but is something you should get used to if you want to eventually be a serious C++ programmer. See also Why is "using namespace std" considered bad practice?.
main() vs int main():
This is not something that Code::Blocks should allow because it is not correct C++. main should always return int.
Overall you seem to have hit an unfortunate number of differences between environments/compilers on this basic example already. However, neither your course nor VS2017 is wrong so far, so I recommend you keep using them. If something that your lecturer writes won't work for in a different environment, it's probably a bad idea to write that kind of code in the first place. And they did make several mistakes in this simple example.
PS: I strongly recommend enabling warnings, because they may tell you when you do something wrong in a more subtle way. There are many mistakes (of the "shooting yourself in the foot" kind) that the compiler is not required to stop you from making, but if you ask to be stopped (by heeding warnings) it will help you.
Using Visual Studio should be okay as long as you disable precompiled headers and your tutorial uses standard-compliant code.
About precompiled headers :
Visual Studio enables pre-compiled headers by default in a C++ command line program. This means that in your project, it'll by default force you to use a precompiled header in the first line of your source code (pch.h here).
By disabling them, you can almost* make the first snippet work in VS. To do this, select your project, go to the "Project->Properties" menu, then to the "Configuration Properties -> C/C++ -> Precompiled Headers" section, then change the "Precompiled Header" setting to "Not Using Precompiled Headers" option (this applies to VS 2012, applying this to other versions of VS should be easy).
If you want to avoid this in the future, you can create an empty project when setting up your project in VS.
See also : http://msdn.microsoft.com/en-us/library/h9x39eaw%28v=vs.71%29.aspx, How to avoid precompiled headers
* : The first snippet won't actually work since the declaration of main is not correct C++, only C (see https://en.cppreference.com/w/cpp/language/main_function, What is the proper declaration of main?)
To your actual question, VS will be fine for your course, although I'm still puzzled by the lecturer's original version of this code.
However, it's really useful to take the time to understand what all your changes did, and why they fixed your problem. Maybe you did this already - that's just not the impression I got from the phrase
What I figured out would work after some googling
when you get a compile error or warning, read it and try to understand it.
if you don't understand the error - and this is normal, certainly while you're learning - then hacking on the code until it works is perfectly fine. At least sometimes it's quicker, and the knowledge that you made progress is its own reward.
if hacking away at the code with the internet at your disposal doesn't get a solution, you'll just have to study the error message more. Turning all compiler errors and warnings on, and trying multiple compilers can both help - even if they all fail, the messages might be more useful. (I often find clang has useful errors, and godbolt.org is super helpful).
if hacking away at the code does get a solution, you should still try and understand why. Now you can see what you changed, look at the original error and try to understand why your changes fixed it. If you made multiple changes, were they all really necessary? Do you understand what they all did, and why?
If you do this, you can fix the next related problem faster, rather than going through the whole trial-and-error process again. You can even write better code that avoids the problem in the first place.
This is the part that actually constitutes learning, which is why I'm making a point of addressing it.
The important fix was changing the lines
include <iostream>
main()
to
#include <iostream>
int main()
because the former aren't legal C++. If your lecturer really wrote exactly that and you didn't somehow mis-copy, then I have no idea why their example worked.
The Visual Studio-specific stuff is the precompiled header, as described in Gabriel's answer.
But the remaining change is essentially cosmetic. Replacing:
using namespace std;
with
using std::cout;
Doesn't affect anything in your code, and just using
std::cout << "Hello world! :-)";
(with no using at all) would work just as well.
The project I'm working on recently made a big effort to cleanup the code by turning on all the strictest GCC warnings and iterating until it compiled. Now, for instance, compilation fails if I declare a variable and don't use it.
After my latest development task there I see that there is a header file included somewhere that is now unnecessary. Is there any good way to find other such header files (and in such a way reduce dependencies) other than trying to remove a header file and seeing if anything breaks?
I am using GCC 4.3.2 on Linux.
No, there's no way to get gcc to fail if a header isn't required. Included headers can contain pretty much anything, so it is assumed that whoever included them had good reason to do so. Imagine the following somewhat pathological case:
int some_function(int x) {
#include "function_body.h"
return x;
}
It's certainly not good form, but it would still compile if you removed the include. So, an automatic checker might declare it "unnecessary," even though the behavior is presumably different when the function body is actually there.
This question HAS had to be asked before, so it kills me to ask it again, but I can't find it for all of my google and searching stackoverflow.
I'm porting a bunch of linux code to windows, and a good chunk of it makes the assumption that everything is automatically initialized to zero or null.
int whatever;
char* something;
...and then immediately doing something that may leave 'something' null, and testing against 'something'
if(something == NULL)
{
.......
}
I would REALLY like not to have to go back throughout this code and say:
int whatever = 0;
char* something = NULL;
Even though that is the proper way to deal with it. It's just very time consuming.
Otherwise, I declare a variable, and it's initialized to something crazy if I don't set it myself.
This option doesn't exist in MSVC, and honestly, whoever coded your application made a big mistake. That code is not portable, as C/C++ say that uninitialized variables have an undefined value. I suggest setting the "treat warnings as errors" option and recompiling; MSVC should give you a warning every time a variable is used without being initialized.
No - there's no option to do that in MSVC.
Debug builds will initialize them with something else (0xcc I think), but not zero. Unfortunately, your code is bugged and needs fixed (of course this applies only to automatic variables -for statics and globals it's fine to assume they're zero initialized). I'm surprised there was any compiler that supported that behavior - if there's an option to do that in GCC, I haven't heard of it (but I'm no expert in the dusty corners of GCC).
You may hear that an earlier version of MSVC would init variables to zero in debug builds (similar to the way 0xcc is used in VS 2005), but as far as I know that's untrue.
edit ----------
Well, I'll be damned - GCC does (or did?) have the -finit-local-zero option. Looks like it's there mostly for Fortran support, I think.
I'd suggest using compiler warnings about using uninitialized variables to help you catch 99% of your problems. I know it's not a great bit of work, but it should be done if at all possible.
Interestingly, MSVC now does have the ability to do this. The Microsoft Security team wrote a blog post about it here, and there's a CppCon talk here.
Unfortunately, it doesn't seem like this option is exposed to the public. This page lists a bunch of 'hidden MSVC flags', and it includes an option called -initall, so that might be it.
What I ended-up doing was switching to /w4. At this level, it caught most of the "yeah, that's going to be an issue" areas of initialization. Otherwise, there's nothing that can change everything from being 0xcccccccc on initialization to 0x00000000 that I saw.
Massive thanks to everyone for answering this, and yes, we will tighten it up in the future.