I'm trying to install cgminer on OS X using MacPorts. It's been nothing but trouble since the start, but with the proper tools, common sense, and the Internet I've been able to get this far. Essentially, the compilation jams on sudo make install indicating a jam at line 956 of util.c - here is the text of the terminal output:
CC cgminer-cgminer.o
CC cgminer-util.o
util.c: In function ‘nanosleep_abstime’:
util.c:956: error: label at end of compound statement
make[1]: *** [cgminer-util.o] Error 1
make: *** [install-recursive] Error 1
And here is the contents of the cgminer copy of util.c opened in Xcode 4.6.3, cropped at nano sleep_abstime and with a comment inserted designating line 956:
static void nanosleep_abstime(struct timespec *ts_end)
{
uint64_t now_ns, end_ns, diff_ns;
struct timespec ts_diff;
struct timeval now;
end_ns = timespec_to_ns(ts_end);
gettimeofday(&now, NULL);
now_ns = timeval_to_ns(&now);
if (unlikely(now_ns >= end_ns))
goto out;
diff_ns = end_ns - now_ns;
ns_to_timespec(&ts_diff, diff_ns);
nanosleep(&ts_diff, NULL);
out:
#ifdef WIN32
timeEndPeriod(1);
#endif
} // LINE 956
#endif
Now, I'm not in any way, shape or form familiar with Unix/Linux commands or terminal in the least - I feel like a fish out of water, so everything I've learned I've had to learn by doing it wrong and then learning the hard way. However, I've read online that this error was solved by ending a label that was unresolved at the last portion of a function - that is, if the function ended at default:, a break; was placed between it and the end brace to resolve the error.
However, I have tried placing the break after the WIN32 #endif, inside the #ifdef preprocessor argument, and preceding it, directly after out:. All continue to fail the compiler. Any solutions for this? I feel like the solution is staring me in the face.
Here is relevant config/version information of my setup:
OS X 10.8.4 (12E55)
Xcode 4.6.3 w/ Command Line Tools installed
MacPorts version 2.2.0
It appears that this code has not been compiled on anything except Windows! Outside Windows, the #ifdef WIN32...#endif evaporates and, as you've seen, the label out: is left without a statement to label.
This is probably most clearly fixed by adding a null statement, explicitly for the non-Windows case:
out:
#ifdef WIN32
timeEndPeriod(1);
#else
;
#endif
}
(The two lines #else and ; have been added.)
Related
When compiling the example hello-world.c for PDCurses, the linker can't seem to find the endwin() function only. Commenting out the line containing endwin(), the code compiles fine and the program runs.
Here's the example code, taken from here (from source/pdce0.c):
#include <curses.h>
/* hello world, initialize curses */
int main()
{
initscr();
printw("Hello World !!!");
refresh();
getch();
endwin();
return 0;
}
When compiling using the mingw64 shell, the following error get's thrown
$ gcc -W -Wall -Ic:/Tools/msys64/mingw64/include/pdcurses -o test hello-world.c -lpdcurses
C:/Tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Tools\msys6
4\tmp\ccsKgZ37.o:hello-world.c:(.text+0x39): undefined reference to `endwin_x64_4302'
collect2.exe: error: ld returned 1 exit status
As stated above, commenting out endwin() in the code leads to compilation without error.
My setup is a MSYS2 installation on Win10 and I installed the mingw64 toolchain and PDCurses for mingw64 according to the steps described by the MSYS doc and this question.
I tried linking the curses lib in different ways, -lncurses, -llibpdcurses, but this does not help.
I tried the curses.h found in the above stated GitHub repo, it looks much simpler, but all this does is change the error to undefined reference to 'endwin'.
Edit 1 regarding comments
Concerning the internal definition of endwin() as a macro, I found this part in the include\pdcurses\curses.h
#ifdef PDC_WIDE
#ifdef PDC_FORCE_UTF8
#ifdef CHTYPE_32
#define endwin endwin_u32_4302
#else
#define endwin endwin_u64_4302
#endif
#else
#ifdef CHTYPE_32
#define endwin endwin_w32_4302
#else
#define endwin endwin_w64_4302
#endif
#endif
#else /* 8-bit chtypes */
#ifdef CHTYPE_32
#define endwin endwin_x32_4302
#else
#define endwin endwin_x64_4302
#endif
#endif
A comparable definition is not included in the curses.h from the examples repo.
Still, endwin() doesn't seem to be defined in the lib.
I already tried reinstalling the pdcurses package via pacman, but everything seems to be fine on that end.
Could using another of the MSYS shells or another package be of help? I'll see what I can find out.
Edit 2
I just took a look at some of the other examples and found out, that adding an infinite loop like
int main()
{
initscr();
printw("Hello World !!!");
while(1){
refresh();
}
getch();
endwin();
return 0;
}
also compiles without the error, but of course produces an unresponsive program.
I have to add that I'm rather new to C, compiling and everything, so if this problems requires some further reading, I'd be glad about suggestions.
Using #include <pdcurses.h> lets it compile without error (this is kinda the direction, John Bollinger mentioned in his comment). I found this issue on the MSYS2/MINGW-Packages GitHub, leaving the impression, that my installation/build version of pdcurses might need some attention. Like one of the commenters there, I thought, that linking against pdcurses didn't need changes of the included headers. I'll look into the setup more thoroughly.
But just to get started and try some things out, everything seems to work for now.
I am trying to use make under Mac OS X (El Capitan) to compile a program which I know to work under Linux. The program makes use of USB libraries. I had to modify the config.mk file for these libraries to be found, but now I end up with errors in the compilation (undeclared identifiers).
Link to source: https://github.com/pali/0xFFFF
It requires usb.h, which seems to be part of usblib-compat. I installed the latter by brew install usblib-compat. But still usb.h couldn't be seen, although I knew where it was: specifically, symbolic link to usb.h and to the library may be found under /usr/local/include and under /usr/local/lib, respectively.
After many trials, I progressed somehow. Namely, the file config.mk is clearly read during the make'ing process, although I have to admit that it is not clear to me how this is done; anyway, I noticed two lines commented:
CPPFLAGS += -I/usr/local/include
LDFLAGS += -L/usr/local/lib -Wl,-R/usr/local/lib
(for the sake of precision, in the original config.mk the local dir was replaced by a pkg dir. I replaced it in these lines.)
I uncommented them and now something happens: the usb.h is found. I think the first of these variable definitions tells the compiler where to look tor header files, and the second tells the linker where to look for libraries - but again it is not completely clear to me.
In any case, I have still problems. Namely, the make'ing process outputs two warnings and an error, and then stops:
usb-device.c:90:57: warning: unused parameter 'udev' [-Wunused-parameter]
static void usb_reattach_kernel_driver(usb_dev_handle * udev, int interface) {
^
usb-device.c:90:67: warning: unused parameter 'interface' [-Wunused-parameter]
static void usb_reattach_kernel_driver(usb_dev_handle * udev, int interface) {
usb-device.c:324:13: error: use of undeclared identifier 'RTLD_DEFAULT' if ( dlsym(RTLD_DEFAULT, "libusb_init") )
Seems this program is difficult to port from Linux to Mac, although I think it should be portable. If anyone has any idea about what to do (apart from running a Linux distribution...), it would be much appreciated.
EDIT
dlfcn.h has the following:
#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
#define RTLD_NOLOAD 0x10
#define RTLD_NODELETE 0x80
#define RTLD_FIRST 0x100 /* Mac OS X 10.5 and later */
/*
* Special handle arguments for dlsym().
*/
#define RTLD_NEXT ((void *) -1) /* Search subsequent objects. */
#define RTLD_DEFAULT ((void *) -2) /* Use default search algorithm. */
#define RTLD_SELF ((void *) -3) /* Search this and subsequent objects (Mac OS X 10.5 and later) */
#endif /* not POSIX */
Ok, finally I have been successful. I think it be worth publishing my solution - maybe others could find it useful.
So, the first point is: if I run make in the program's main folder, usb.h is not found. Then, we have to install the corresponding library.
There are two possibilities for this to be done. The first and more obvious would be to install, through home brew, libusb-1.0 and libusb-compat (the latter provides a compatibility interface for programs that use libusb-0.1, which is the first version of libusb, and is not compatible with libusb-1.0. usb.h is included in libusb-compat):
brew install libusb
brew install libusb-compat
However, this leads to other problems, as reported in the other answer. I had worked around them, but eventually found out that my program got angry when using libusb-compat (if I understand correctly, interfacing the usb port through two layers of libraries is too slow for a flasher).
So, the other possibility: installing the actual libusb-0.1. This is not available through home brew. It is however available through ports, with the name of libusb-legacy. So, I had to install ports, install the X-code command line utilities (which required first going to Apples' website to accept their legal things...) and run
sudo port install libusb-legacy
Ok, now calling make would not do the trick since the compiler is not able to find the library yet. For that, I had to edit the config.mk file which is included in the main directory of the program, uncommenting the last two lines, and editing them somewhat in order to point to the directory where libusb-legacy is stored:
CPPFLAGS += -I/opt/local/include/libusb-legacy -D_DARWIN_C_SOURCE
LDFLAGS += -L/opt/local/lib/libusb-legacy
(the -D_DARWIN_C_SOURCE defines the environmental variable required for other variables to be defined by the libraries. In the Makefile in the src directory, in fact, _POSIX_C_SOURCE is defined.)
Do you think all this did the job? No. In fact at this point I ended up with another error: the linker not being able to find some library called -lusb. I don't know why this syntax, but after some thought I realised that -lusb is somewhat a short for libusb. And the libusb I am using is actually called libusb-legacy... So I went into the Makefile in the src directory, where -lusb is introduced, and changed -lusb to -lusb-compat. Tah-dah! Compiled. A few warnings about non-used variables and a comparison between two different types of integers, but nothing more. And the program runs - after a few trials, I have been able to reflash my bricked phone, which now is alive again! Very happy!!! :)
Looking at the dlfcn.h source code, it seems that the identifier is defined only if _POSIX_C_SOURCE is not defined, or _DARWIN_C_SOURCE is defined. Thus I'd just add #define _DARWIN_C_SOURCE;
Or you could add the corresponding -D switch in the config.mk:
CPPFLAGS += -I/usr/local/include -D_DARWIN_C_SOURCE
I run debian linux actual stable with splint and mingw installed.
I want to check my c code (which I need to compile with mingw, sorry) by splint. Simply adding the mingw-includes is not enough to run. I tried with defining GNU and i686 - but I'm sure more is needed. What further do I have to define or include?
I tried the idea from loan resulting in a problem with __builtin_va_list.
Splint 3.1.2 --- 20 Feb 2009
/usr/i686-w64-mingw32/include/vadefs.h:24:43: Parse Error:
Suspect missing struct or union keyword: __builtin_va_list :
int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
The funny thing is, that I can not find any definition for not - even with a recursive grep on the include folders. Am I searching wrong?
By defining it the way -D__builtin_va_list=va_list (from benjarobin) I ran into the error
Splint 3.1.2 --- 20 Feb 2009
/home/ebelingb/.splintrc:229:1: Setting -stats redundant with current value
/home/ebelingb/.splintrc:229:1: Setting -showsummary redundant with current
value
/usr/i686-w64-mingw32/include/winnt.h:2390:15:
Parse Error. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
which could not be recovered even by +trytorecover.
The lines from winnt.h (and neighbouring) reads
2388 typedef struct _EXCEPTION_POINTERS {
2389 PEXCEPTION_RECORD ExceptionRecord;
2390 PCONTEXT ContextRecord;
2391 } EXCEPTION_POINTERS,*PEXCEPTION_POINTERS;
Strange, isn't it?
Okay as this thread gets no further answers, I'll give some motivation by this minimal not working example:
Given a file test.c
#include <windows.h>
#include <stdio.h>
#include <time.h>
#define LOGFILEFORMAT "C:\\CBM\\log\\%Y%m%d.log"
#define LOGTIMESTAMPFORMAT "%Y-%m-%d %H:%M:%S"
int main() /*int argc,char **argv*/{
Sleep(1234);
return (0);
}
and my .splintrc
-I/usr/lib/gcc/i686-w64-mingw32/4.6/include
-I/usr/lib/gcc/i686-w64-mingw32/4.6/include-fixed
-I/usr/i686-w64-mingw32/include
the easy command splint test.c fails:
Splint 3.1.2 --- 20 Feb 2009
/usr/i686-w64-mingw32/include/_mingw.h:480:29: Parse Error:
Suspect missing struct or union keyword: __int64 :
long int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
Again I do not know, how to setup. The includes above result from a preprocesing call of the compiler i686-w64-mingw32-gcc, which runs fine on test.c.
You can get a good list of preprocessor defines using a blank C source file and running it through GCC/MinGW with your desired custom arguments:
gcc -E -P -v -dD [optional arguments] blank.c
Be sure to use the proper compiler for your target. You can redirect the output to a file and pass whatever defines you may need from there to splint.
Pretty much what the title says. I have been trying to build RabbitMQ under Windows using MinGW with no success. Judging by the amount of people I see asking questions about how to use it, I suspect I am making a silly mistake, but I don't know what it is. I'm on Win7-64 and I'm extracting the repo, creating a build directory in it, and running
cmake -G "MinGW Makefiles" ..
which seems to work, and then
cmake --build .
which throws a bunch of function re declaration errors. Does anybody know what I'm botching here?
Just for good measure, a small sampling of the errors:
Linking C shared library librabbitmq.1.dll
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x3c): mult
iple definition of `amqp_empty_array'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x0):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x44): mult
iple definition of `amqp_empty_table'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x8):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x4c): mult
iple definition of `amqp_empty_bytes'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x10)
: first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_connection.c.obj):amqp_connection.c:(.bss
+0x0): multiple definition of `amqp_empty_array'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x0):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_connection.c.obj):amqp_connection.c:(.bss
+0x8): multiple definition of `amqp_empty_table'
CMakeFiles\rlibrabbitmq\CMakeFiles\rabbitmq.dir\build.make:271: recipe for targe
t 'librabbitmq/librabbitmq.1.dll' failed
EDIT:
After some time, I have determined that the problem is that the pre-processor directives have some errors in the way they are written. I'm not going to close this for now, and if I ever get the time to fix the whole thing, I will come back here and leave an answer with a solution.
I've been analyzing macros defined in amqp.h file and I've added the extern modifier to the AMQP_PUBLIC_VARIABLE macro when build a non static library.
78 #elif defined(_WIN32) && defined(__MINGW32__)
79 # if defined(AMQP_BUILD) && !defined(AMQP_STATIC)
80 # define AMQP_PUBLIC_FUNCTION __declspec(dllexport)
81 # define AMQP_PUBLIC_VARIABLE __declspec(dllexport) extern
Another thing was, that I've had to modify the WINVER macro on file '/MinGW/include/windef.h' inside MinGW environment to fit with new windows versions.
11 #ifndef WINVER
12 #define WINVER 0x0501
After that, I've built the librabbitmq.1.dll library without problems using cmake -G "MinGW Makefiles" .. && cmake --build . commands
I have been trying to compile netcat.c on AIX for some time (using the command make aix), but the compiler gives me some weird feedback such as :
"netcat.c", line 117.12: 1506-275 (S) Unexpected text 'int' encountered.
when checked the file netcat.c at line 117, I would find the line (second line in code below):
#ifdef HAVE_BIND
extern int h_errno;
/* stolen almost wholesale from bsd herror.c */
even if I changed the int into char for the same of testing, save the file and re-run the command I get the same error
am I missing something in reading the error code?
If you're using xlc (especially older ones), it's normally caused by declarations after statements, something like:
i = i + 1;
int x;
You probably need to give us a little more context, such as 10 or so lines before the error line.
My advice would be to get gcc running on that box if you are using an older xlc. IBM makes some fine compilers now but the earlier ones weren't so crash hot (in my opinion).
When innocent-looking code produces bizarre errors, try running the code through the C preprocessor stage, and looking at it then. Sometimes macros do very funny things.
Also note that a problem on an earlier line (missing semicolon, etc.) might produce an error message on a later line.
The post maybe already a little outdated, but just in case someone else comes along with the same problem ...
Here (AIX 7.1) h_errno is defined as macro in netdb.h.
/usr/include/netdb.h:#define h_errno (*(int *)h_errno_which())
Therefore the declaration in netcat.c line 117 does not work.
I just changed the line into
#ifndef h_errno
extern int h_errno;
#endif
and the compilation worked smoothly.
#A.Rashad, I moved the HAVE_BIND #ifdef block from line 117 to line 30 which is just under the #include "generic.h" declaration. This permitted the xlc to compile it. The (S)yntax error messages are gone and while there are some (W)arning messages, I do get an nc binary at the end!
hth,
Kevin