This question already has answers here:
Compiling C++ on remote Linux machine - "clock skew detected" warning
(14 answers)
Closed 2 years ago.
I am uploading my OpenCL and Cuda code to hgpu.org because I don't have a graphics card on my laptop. When I upload my code I get the following error:
make: Warning: File `main.cu' has modification time 381 s in the future
make: warning: Clock skew detected. Your build may be incomplete.
I know that clock skew is due to difference in my machines clock time and the server's clock time, so I synchronized my time with the server's. The OpenCL and C++ code is running fine now but the Cuda code is still giving me this error.
So my question is:
Is there any other reason for clock skew error besides the time synchronization? And if there is then how do I solve it?
Cuda Code:
__global__
void test()
{
}
int main()
{
dim3 gridblock(1,1,1);
dim3 threadblock(1,1,1);
test<<<gridblock,threadblock>>>();
return 0;
}
Note: I can provide the make file too.
Simply go to the directory where the troubling file is, type touch * without quotes in the console, and you should be good.
One of the reason may be improper date/time of your PC.
In Ubuntu PC to check the date and time using:
date
Example, One of the ways to update date and time is:
date -s "23 MAR 2017 17:06:00"
I am going to answer my own question.
I added the following lines of code to my Makefile and it fixed the "clock skew" problem:
clean:
find . -type f | xargs touch
rm -rf $(OBJS)
please try to do
make clean
(instead of make), then
make
again.
Related
This question already has an answer here:
make: Nothing to be done for `all'. when i tried to compile
(1 answer)
Closed 5 months ago.
Here is my snippet of code that's giving me this error, it is in Fortran. If you want more code I can amend this one if it helps.
[cba78749#bridges2-login012 ~]$ cd FFB0D
[cba78749#bridges2-login012 FFB0D]$ ls
BGKVDCF0D_commvar.f90 BGKVDCF0D_spat_oper_mod.o DGV_commvar.f90 DGV_miscsetup.o Makefile_debug bgkvdcf0d_spat_oper_mod.mod dgv_readwrite.mod gaussquad.mod nrroutines_mod.o
BGKVDCF0D_commvar.o BGKVDCF0D_time_integr_mod.f90 DGV_commvar.o DGV_mpiroutines.f90 Makefile_production bgkvdcf0d_time_integr_mod.mod dgv_sf02.mod gaussquad.o nrtype.f90
BGKVDCF0D_miscset.f90 BGKVDCF0D_time_integr_mod.o DGV_dgvtools_mod.f90 DGV_readwrite.f90 algama.f dgv_collision_mod.mod ffbM300.a makemake.perl nrtype.mod
BGKVDCF0D_miscset.o BGKVDCF0Driver.f90 DGV_dgvtools_mod.o DGV_readwrite.o algama.o dgv_commvar.mod gaussian_mod.f90 mkl_dft_type.mod nrtype.o
BGKVDCF0D_readwrite.f90 BGKVDCF0Driver.o DGV_distributions_mod.f90 DGV_sf02.f90 bgkvdcf0d_commvar.mod dgv_dgvtools_mod.mod gaussian_mod.mod mkl_dfti.mod nrutil.f90
BGKVDCF0D_readwrite.o DGV_collision_mod.f90 DGV_distributions_mod.o DGV_sf02.o bgkvdcf0d_miscset.mod dgv_distributions_mod.mod gaussian_mod.o nrroutines_mod.f90 nrutil.mod
BGKVDCF0D_spat_oper_mod.f90 DGV_collision_mod.o DGV_miscsetup.f90 Makefile bgkvdcf0d_readwrite.mod dgv_miscset.mod gaussquad.f90 nrroutines_mod.mod nrutil.o
[cba78749#bridges2-login012 FFB0D]$ make
make: Nothing to be done for 'all'.
I'm very new to PuTTY, and I'm trying to compile the code
It has nothing to do with putty. When you run make it looks for the Makefile (with exactly this capitalisation) and tries to make the first target it sees, in your Makefile that seems to be the target "all".
If the first target depends on other targets that haven't been met yet, it will also make those.
It is not uncommon to have the all target as the first target that simply depends on all the targets in the Makefile, that way running make will create all targets.
But if all targets are already made, meaning the files declared as target are newer than their own dependencies (sources), nothing needs to be made, and you get the message that you are inquiring about.
I strongly recommend reading up on the make command, for example here: https://linuxhint.com/gnu-make-tutorial/
When compiling cross-compiler tool crosstool-0.43 (for arm9) on the CentOS 7.5 64-bit system, I encountered the following error：
cc -c -o flat_bl.o /home/muhuo/arm-linux-project/transplant-test/build-tools/crosstool-0.43/build/arm-9tdmi-linux/gcc-4.1.0-glibc-2.3.2/binutils-2.16.1/gprof/flat_bl.m
/home/muhuo/arm-linux-project/transplant-test/build-tools/crosstool-0.43/build/arm-9tdmi-linux/gcc-4.1.0-glibc-2.3.2/binutils-2.16.1/gprof/flat_bl.m:2:2: error: expected identifier or ??before ??token
% the percentage of the total running time of the
^
I don't know what the *. m file in binutils-2.16.1 is. Whether I need to install some other tools before?
From the picture above, Compiling *.m file with GCC should be wrong.
I need some help. Thanks.
The problem is that there is a builtin '.m.o' suffix rule which triggers with a higher priority than the '.c.o' suffix rule. There was an attempt to disable this rule under PR2587 but because it is an old-style suffix rule this doesn't work.
There are two possible solutions, one is to remove all builtin rules by adding the line .MAKEFLAGS: -r to binutils/gprof/Makefile.in somewhere, or else more correctly change the .SUFFIXES: line in the same file so that the '.m' comes after '.c', thus changing the rule priority.
Let me start out with a disclaimer:
I am new to writing my own makefiles and have just had a few days of research and tinkering around with my own makefile to try to figure things out. I have also Googled this question and spent a fair amount of time looking for an answer but haven't found one. There are many things I am inexperienced with, so if I ask a stupid question, please bear with me (and try to help me understand it).
I have made a makefile that I have been testing out to see if my understanding is correct, and so far everything here makes sense and works until it gets to $(CC). I'm on windows 7 using cygwin64 terminal and it gives this output after I type make:
make: tricore-gcc: Command not found
make: *** [Makefile:20: test_eeprom.o] Error 127
So why can't it recognize my compiler? Why does it say "Command not found?" I know the compiler is installed because I have used it for existing projects on my computer and just now am starting to write my own makefile and try to use it. I have even seen in other makefiles that were made by someone previous to me that they define the compiler the same way as me in the makefile.
For reference, here is my makefile:
#Test module Makefile
#compiler
CC = tricore-gcc
#path to MBD header files
MBDPATH = ../../../../../../Application/MBD/build/test_ert_rtw
#where the source code is
SRC = Src
#object files to be made
DS_OBJ = test_eeprom.o test_gd.o test_task.o \
sct_conf.o unimportant_name.o
#rule to make test eeprom object
test_eeprom.o: $(SRC)/test_eeprom.c $(SRC)/test_eeprom.h $(SRC)/test_task.h \
$(MBDPATH)/test.h
$(CC) -c test_eeprom.
First time posting on stackoverflow!
I'm just getting started on using GNU make. I'm using a simple example Makefile described here (and printed below). There are two steps to be completed by the Makefile, both of which I can complete without error without using make.
Here's the Makefile (truncated from original because I don't have topojson installed):
counties.zip:
curl -o counties.zip 'http://www2.census.gov/geo/tiger/GENZ2010/gz_2010_us_050_00_20m.zip'
gz_2010_us_050_00_20m.shp: counties.zip
unzip counties.zip
touch gz_2010_us_050_00_20m.shp
When I attempt to use make make -f Makefile or just make, I get the following:
curl -o counties.zip 'http://www2.census.gov/geo/tiger/GENZ2010/gz_2010_us_050_00_20m.zip'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1277k 100 1277k 0 0 955k 0 0:00:01 0:00:01 --:- -:-- 956k
The file successfully downloads, but is never unzipped in the next step. If I type make again, it prints:
make: `counties.zip' is up to date.
I've tried similar simple multi-step test cases and the same thing is happening - the first step is completed, but no subsequent steps are. I know I've installed programs using make in the past on this machine (Ubuntu 14.04.3 LTS).
Any help would be greatly appreciated. Apologies if I've forgotten any relevant details or this is a redundant question.
You need to add the rule at the beginning of the Makefile.
all: counties.zip gz_2010_us_050_00_20m.shp
Make sure all are the same, there is a good tutorial here, it is basic.
Edit (updated question)
I have a simple C program:
// it is not important to know what the code does you may skip the code
main.c
#include <bsp.h>
unsigned int AppCtr;
unsigned char AppFlag;
int SOME_LARGE_VARIABLE;
static void AppTest (void);
void main (void)
{
AppCtr = 0;
AppFlag = 0;
AppTest();
}
static void Foo(void){
SOME_LARGE_VARIABLE=15;
}
static void AppTest (void)
{
unsigned int i;
i = 0;
while (i < 200000) {
i++;
}
BSP_Test();
SOME_LARGE_VARIABLE=3;
Foo();
}
bsp.c
extern int SOME_LARGE_VARIABLE;
extern unsigned char AppFlag;
unsigned int long My_GREAT_COUNTER;
void BSP_Test (void) {
SOME_LARGE_VARIABLE = 5;
My_GREAT_COUNTER = 4;
}
(the program does not do anything useful... My goal is to extract the variable names their location where they are being declared and their memory address)
When I compile the program I get the file a.out which is an elf file containing debug information.
Someone on the company wrote a program in .net 5 years ago that will get all this information from the a.out file. This is what the code returns:
// Name Display Name Type Size Address
For this small program it works great and also for other large projects.
That code is 2000 lines long with several bugs and it does not support .NET version 4. That's why I am trying to recreate it.
So my question is, I am lost in the sense that I don't know what approach to take in order to solve this problem. These are the options I have been considering:
Organize the buggy code of the program I showed on the first image and try to see what it does and how it parses the a.out file in order to get that information. Once I fully understand it try to figure out why it does not support version 3 and 4.
I am ok at creating regex expressions so maybe try to look for the pattern in the a.out file by doing something like: So far I was able to find the pattern where there is just one file (main.c). But when there are several files it get's more complicated. I haven't tried it yet. Maybe it will be not that complicated and it will be possible to find the pattern.
Install Cygwin so that I can use linux commands on windows such as objdump, nm or elfread. I have't played enough with the commands when I use those commands such as readelf -w a.out I get way more information that I need. There are some cons why I have not spend that much time with this approach:
Cons: It takes a while to install cygwin on windows and when giving this application to our customers we don't want them to have to install it. Maybe there is a way of just installing the commands objdump and elfread without having to install the whole thing
Pros: If we find the right command to use we will not be reinventing the wheel and save some time. Maybe it is a matter of parsing the results of a command such as objdump -w a.out
In case you want to download the a.out file in order to parse it here it is.
Summary
I will to be able to get the global variables on a.out file. I will like to know what type each variable is (int, char, ..), what memory address they have and I will also like to know on what file the variable is being declared (main.c or someOtherFile.c). I will appreciate if I don't have to use cygwin as that will make it more easy to deploy. Since this question asks for a lot, I attempted to split it into more:
objdump/readelf get variables information
Get location of symbols in a.out file
perhaps I should delete the other questions. sorry being redundant.
Here is what I will do. Why reinvent the wheel!
Download linux commands that will be needing on windows from here.
on the bin directory there should be: readelf.exe
Note we will not need Cygwin or any program so deploying will be simple!
Once we have that file execute in cmd:
// cd "path where readelf.exe is"
readelf.exe -s a.out
and this is the list that will come out:
so if you take a look we are interested in getting all the variables that are of type OBJECT with size greater than 0.
Once we got the variables we can use the readelf.exe -w a.out command to take a look at the tree and it looks like: let's start looking for one of the variable we found on step 2 (SOME_GREAT_COUNTER) Note that at the top we know the location where the variable is being declared, we got more information such as the line where it was declared and the memory address
The last thing we are missing to do is to get the type. if you take a look we see that the type is = <0x522>. What that means is that we have to go to 522 of the tree to get more info about that time. If we go to that part this is what we get: From looking at the tree we know that SOME_LARGE_VARIABLE is of type unsigned long