My project sometimes benefits from ccache, so I have long been using ccache. I'm now adding precompiled headers. Some sources suggest that the two are incompatible and that one must choose between them. But I find in ccache's documentation that it does support PCH on some level: https://ccache.samba.org/manual.html#_precompiled_headers
Indeed, when I try using ccache to build a .o file while using Clang's -include-pch option, I see that ccache is succeeding at caching the .o. The first compilation attempt takes 1.5 s, and a second takes only 0.05 s (because ccache has done its job).
The trouble is that if I run this same compilation command with clang++ instead of with /usr/lib/ccache/clang++, it takes 0.5 s... unless I leave off the -include-pch part, in which case it takes about 1.5 s. It seems that ccache may be causing my PCH to be ignored, or something.
I've followed the instructions (from the link above). As specified there, my ccache.conf looks like this:
sloppiness=pch_defines,time_macros
And I've tried every reasonable combination of #include, -include, -include-pch, and -fpch-preprocess I could think of. Compilation always takes 1.5 s and then 0.05 s, when it should take 0.5 s, and then 0.05 s.
Is it possible to make this work, or do I have to choose between ccache and PCH after all?
Related
I use both GNU Make and - woe is me - ClearCase' clearmake.
Now, GNU make respect a flag named MAKEFLAGS, which for me is set to j20 on this multi-core machine I'm on. Unfortunately, clearmake also recognizes this option, yet doesn't except this value. It tells me:
clearmake: Error: Bad option (j)
clearmake: Error: Bad option (2)
clearmake: Error: Bad option (0)
Questions:
Why is this happening? Should ClearMake accommodate GNU Make's usage?
How can I get around it, other then turning the flag off an on repeatedly?
It's been 15 years or so since I used clearmake, but assuming it doesn't support the GNU make-specific GNUMAKEFLAGS variable you can use:
export GNUMAKEFLAGS=-j20
and leave MAKEFLAGS unset.
The "BUILDING SOFTWARE WITH CLEARCASE" clearly states in its T"unsupported Gnu make features" that this option is indeed not supported.
–j [JOBS]
--jobs=[JOBS]
Maybe a clearmake -C -J can help (for testing): there should then be no limit to the number of parallel builds.
Are you calling GNU make from a clearmake build script? Or are you trying to create a single makefile that will support both build tools? I think the GNUMAKEFLAGS EV is safer for GNU make specific values. I would also use
CCASE_MAKEFLAGS for any makeflags that are specific to clearmake.
CCASE_CONC to set the concurrency value. While clearmake no longer passes the -J in MAKEFLAGS, it used to, and if you're using an older clearmake (somewhere in the 7's as I recall), you could upset "child" GNU make sessions since they like -J about as much as clearmake likes -j.
Finally, check the env_ccase man page for the behavior mentioned in CCASE_MAKEFLAGS_V6_OBSOLETE. If you pass MAKEFLAGS explicitly in the build script like
$(MAKE) $(MAKEFLAGS) TARGET=x
And had started clearmake like this:
clearmake -C gnu TARGET=Y
You'll actually get both TARGET macro definitions in the command line. Setting the mentioned EV (at all) avoids the "pass defined macros in MAKEFLAGS" behavior. The switch exists because some people have makefiles that DEPEND on this behavior, while others have ones BROKEN BY this behavior...
Assuming for the sake of argument that your company has a support agreement with either IBM or HCL, this is a good time to use your support channels to bring up clearmake concerns.
I have a C++ library and it has a few of C++ static objects. The library could suffer from C++ static initialization fiasco. I'm trying to vet unforeseen translation unit dependencies by randomizing the order of the *.o files during a build.
I visited 2.3 How make Processes a Makefile in the GNU manual and it tells me:
Goals are the targets that make strives ultimately to update. You can override this behavior using the command line (see Arguments to Specify the Goals) ...
I also followed to 9.2 Arguments to Specify the Goals, but a treatment was not provided. It did not surprise me.
Is it possible to have Make randomize its goals? If so, then how do I do it?
If not, are there any alternatives? This is in a test environment, so I have more tools available to me than just GNUmake.
Thanks in advance.
This is really implementation-defined, but GNU Make will process targets from left to right.
Say you have an OBJS variable with the objects you want to randomize, you could write something like (using e.g. shuf):
RAND_OBJS := $(shell shuf -e -- $(OBJS))
random_build: $(RAND_OBJS)
This holds as long as you're not using parallel make (-j option). If you are the order will still be randomized, but it will also depend on number of jobs, system load, current phase of the moon, etc.
Next release of GNU make will have --shuffle mode. It will allow you to execute prerequisites in random order to shake out missing dependencies by running $ make --shuffle.
The feature was recently added in https://savannah.gnu.org/bugs/index.php?62100 and so far is available only in GNU make's git tree.
There are a few differences noticed in symbols between two binaries built using same sources on two AIX systems. One example for 'main':
xxxx1: .main T 4294975624
xxxx2: .main T 4294969472 516
xxxx2: main:F-1 - 0
Why the difference in sizes?
'T' is Global text symbol as per man page. What is 'F'?
Also, the sizes of two binaries vary significantly: 3924048 vs. 17701460. Why?
AIX versions, compiler versions, makefiles (same CFLAGS) are identical.
I'm fairly sure the F-1 is a function returning int. It is a "stab" string which is output when the compiler given the -g option. That would also be the reason for the size differences.
Can you try doing "size " and "size ". size also has an option to make it more verbose. You can also do "file " etc and it will tell you if it is stripped or not.
Between the -g and the strip flag at link time, I think that will account for the differences you are seeing.
HTH
I am compiling legacy code that calculates color spectra using linear algebra. The matrices use float as the type, and all calculations use float. When we use our old compiler (turbo-linux gcc 2.95) we get one answer. When I use our new compiler (SuSE gcc 4.3.2) we get different spectra.
I need to get the output of the same program compiled using the new compiler to match the output using the old compiler.
I have tried using these compiler options:
g++ -g -lstdc++ -mfpmath=no-sse -mno-sse -mno-sse2 -ffloat-store -mieee-fp
and this code:
volatile unsigned short int cw;
__asm__ volatile("fstcw %0" : "=m" (*&cw));
printf("floating point control word was: %x\n",cw);
cw=0x027f;
__asm__ volatile("fldcw %0" :: "m" (*&cw));
printf("floating point control word now is: %x\n",cw);
None of this enabled the color spectra to match.
The question is then... is there a silver bullet to make the color spectra resulting from code compiled from the two different compilers to match? I was hoping the floating point control width (the flpcw above) was the solution, but it wasn't. (note, the code is too complex to post, ).
P.S. the result of the above code was:
gcc 2.95 floating point control word was: 0x37f
floating point control word now is 0x27f.
gcc 4.3.2 floating point control word was: 0x37f
floating point control word now is 0x27f.
I want to increase the stack size of an ipad application to 16MB .I have done it in xcode build setting "-WI-stack_size 1000000 to the Other Linker Flags field ".
but getting build error of
i686-apple-darwin10-gcc-4.2.1: stack_size: No such file or directory
i686-apple-darwin10-gcc-4.2.1: 1000000: No such file or directory
How can i resolve that ?
Do not know if you got it solved or not, but the correct way to indicate such option to the linker (according to this site) is to add -Wl,-stack_size,1000000 to the Other Linker Flags field of the Build Styles pane. You are missing the commas.
In case you are using clang or gcc the cli would be:
g++ -Wl,-stack_size -Wl,1000000
Hope it helps.
If you think you need to increase the stack size you're almost certainly doing something very wrong in your code, like allocating way too large objects on the stack (ie a 16 MByte C array).
Instead, allocate the memory or use the proper Objective-C data structures (ie NSMutableArray).