Makefile target selection

unix

    Next

  • 1. send(...)
    Hello, Currently debugging a very rare and somewhat strange bug. A tcp communication session between a client and server is suddenly terminated for no apparent reason. This might occurs once within a timeframe of 24 hours with lots of communication. Viewing the tcp communication this happens when communcation breaks down; * TCP handshake * Client sends data * Server acks data * Server sends data and sets FIN=1 which closes the tcp session. Normally the client and server will perform several more send \ recv actions before closing the tcp session gracefully. In this one instance the tcp session is terminated too early. The server method that handles replying executes three send(...) calls; if (sizeof(header) != send(...) { // return error } if (sizeof(data) != send(...) { // return error } if (sizeof(tail) != send(...) { // return error } Viewing the log none of the above mentioned send() calls fail (return -1) but still FIN is being set this one time. Also, Close() is not explicitly called by our application when the communication breaks down. Any thoughts?
  • 2. ncurses pads - basic problem
    Hi all, I can't get pads to work in ncurses at all. Could someone look at the really basic program and tell me why it displays a blank screen please? It doesn't give me any errors, compiling or running, which makes me think I've missed something simple. TIA, Tom #include <errno.h> #include <ncurses.h> #include <stdio.h> #include <stdlib.h> void fail( int status, int errnum, const char *msg ); int main( int ac, char **av ){ WINDOW *pad; initscr(); pad= newpad( 3, 3 ); if( ! pad ) fail( EXIT_FAILURE, errno, "could not create pad" ); if( OK != wmove( pad, 0, 0 )) fail( EXIT_FAILURE, errno, "could not move" ); if( OK != waddch( pad, 'A' )) fail( EXIT_FAILURE, errno, "could not write" ); if( OK != wmove( pad, 1, 1 )) fail( EXIT_FAILURE, errno, "could not move" ); if( OK != waddch( pad, 'B' )) fail( EXIT_FAILURE, errno, "could not write" ); if( OK != prefresh( pad, 0, 0, 0, 0, 2, 2 )) fail( EXIT_FAILURE, errno, "could not refresh" ); wgetch( stdscr ); endwin(); exit( EXIT_SUCCESS ); } void fail( int status, int errnum, const char *msg ){ endwin(); fputs( msg, stderr ); errno= errnum; perror( NULL ); exit( status ); }
  • 3. copy unnamed union in struct
    Below I've included a C program in which an unnamed union is copied from one struct to another. Unnamed unions are an extension supported by many compilers I believe. The restriction I've posed is that the bit of code that does the copying cannot assume anything about which member of the union is active (last set). The code below is ugly because it uses sizeof applied to a *named* clone (union foo below) of the same anonymous union (in struct bar below). I am not sure whether those two unions are guaranteed to have the same size by the C standard. Also it uses offsetof applied to a member of the unnamed union, and uses the result in pointer arithmetic to do the copying using memcpy. Is there a better solution to this problem, and to what extent is this solution viable? Stijn #include <stdio.h> #include <stdlib.h> #include <stddef.h> #include <string.h> union foo { int idx; void* ptr; }; struct bar { double val; union { int idx; void* ptr; }; }; int main ( int argc , char* argv[] ) { struct bar x, y; int t; x.val = 1.43343; x.ptr = "abde"; y.val = 2.888; y.ptr = "xyz"; t = offsetof(struct bar, idx); fprintf(stdout, "x has pointer %p\n", x.ptr); fprintf(stdout, "y has pointer %p\n", y.ptr); memcpy(((char*) &y)+t, ((char*) &x)+t, sizeof(union foo)); fprintf(stdout, "y has pointer %p\n", y.ptr); return 0; }
  • 4. fwrite reports "no space left on device" but there is space left on device
    XXXX@XXXXX.COM writes: > I am using fwrite to write (wb) about 4 gigs of data of type user- > defined struct, and there is plenty of space on the device, yet I am > getting a "no space left on device" errno. The file is opened newly > and it happens on all subsequent file io. Any ideas on where to look? Perhaps you need to enable "large file support"? You didn't say what OS you are using, and whether your program is compiled in 32-bit or 64-bit mode, and whether it fails before or just after the 4GB boundary. If it's a 32-bit program, on many OSes you need to compile it with -D_FILE_OFFSET_BITS=64 before you can write files larger than 4GB. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email.

Makefile target selection

Postby zuheyr alsalihi » Mon, 12 Jul 2004 20:55:27 GMT

Hello,

Is there any way to know in a Makefile which target is wanted to build?
E.g. if I have targets all, A and B, how can I use conditionals in the
Makefile
depening on the target?

Thank you,
Zuheyr



Re: Makefile target selection

Postby Jens.Toerring » Mon, 12 Jul 2004 23:28:30 GMT



The MAKECMDGOALS variable is automatically set to the list of
goals (i.e. targets) you specified on the command line. So you
can do something like

ifeq($MAKECMDGOALS,all)
   do something
endif

Take care, it seems to be GNU make specific.

                                  Regards, Jens
-- 
  \   Jens Thoms Toerring  ___   XXXX@XXXXX.COM 
   \__________________________   http://www.**--****.com/ 

Similar Threads:

1.GNU Makefile with phony target and source files as dependencies of a target

Hello guys,

I have a question about GNU make running on the Solaris 8 platform.
We have a GNU Makefile which has a "depend" target (for the usual
concept of make depend in C++ programming) which looks like this:


depend : prep $(patsubst %.cc,%.o , $(OBJ))
       $(CC) $(CPPFLAGS) -xM1 $? > .depend


Obviously this has a problem, in that the prep target (along with the
depend target) is phony, and so the CC command to generate
dependencies fails with the "prep" value passed as a filename in "$?"
in the command.


I had an idea to change the compilation command to:
       $(CC) $(CPPFLAGS) -xM1 $(filter %.cc,$?) > .depend
and I believe this should work. My question is: while this solution
might work, I'm not sure it is the "preferred" solutoin using GNU
make. Is this a "good enough" solution? Or this there another,
"preferred" solution that is better? If there is, please let me know
what it might be.


Thanks



Return to unix

 

Who is online

Users browsing this forum: No registered users and 8 guest