By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,369 Members | 1,138 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,369 IT Pros & Developers. It's quick & easy.

Can't compile this with Cygwin!

P: n/a
JS
I use winXP and have installed Cygwin. I use Dev-C++ and the Cygwin
compiler, but for some reason I can't compile this code:

#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>
typedef int othread_t;

typedef struct _othread_attr_t {
} othread_attr_t;

#define STACK_SIZE 1024
struct pcb {
void *(*start_routine) (void *);
void *arg;
jmp_buf state;
int stak[STACK_SIZE];
};

static struct pcb first_thread;

struct pcb *current = &first_thread;
struct pcb *ready = NULL;

int othread_create (othread_t *threadp,
const othread_attr_t *attr,
void *(*start_routine) (void *),
void *arg)
{
int *state_pointer;
int lokalt_reserveret;

struct pcb *pcb_pointer;

pcb_pointer = (struct pcb *) malloc(sizeof(struct pcb));
if(pcb_pointer == NULL) {

exit(-1);
}

pcb_pointer->start_routine = start_routine;
pcb_pointer->arg = arg;

if(setjmp(pcb_pointer->state)) {

current->start_routine(current->arg);

printf("En tråd har returneret - alt stoppes\n");
exit(0);
}

state_pointer = (int *) &pcb_pointer->state;
lokalt_reserveret = state_pointer[JB_BP] - state_pointer[JB_SP];
state_pointer[JB_BP] = (int) (pcb_pointer->stak + STACK_SIZE);
state_pointer[JB_SP] = (int) state_pointer[JB_BP] - lokalt_reserveret;
ready = pcb_pointer;
*threadp = (int) pcb_pointer;

return 0;
}
int othread_yield (void)
{
if(ready != NULL) {

struct pcb *old = current;
current = ready;
ready = old;
if(setjmp(old->state) == 0) {
longjmp(current->state, 1);
}
}

return 0;
}

void *other(void *arg)
{
printf("Hello world from other\n");

othread_yield();

printf("other still going strong\n");

othread_yield();

printf("Godbye world from other\n");

return NULL;
}
int main(void)
{
othread_t t1;

othread_create(&t1, NULL, other, NULL);

printf("Hello world from main\n");

othread_yield();

printf("main still going strong\n");

othread_yield();

printf("Godbye world from main\n");

othread_yield();
printf("Is never reached\n");

return 0;
}

The error I get is:

56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
make H:\thread\make *** [thread.o] Error 1

when I compile the same code on Linux it works fine! But I am sure that I
use Cygwin so that should be as good as using Linux.

Hope someone can help

Nov 14 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
JS <sf****@asdas.com> wrote:

<lots of cde snipped>
The error I get is: 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.) 56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
make H:\thread\make *** [thread.o] Error 1 when I compile the same code on Linux it works fine! But I am sure that I
use Cygwin so that should be as good as using Linux.


No, it doesn't compile, not even on Linux. I just took your code
and tried to compile it (under Linux) and, voila,

thr.c:55: error: `JB_BP' undeclared (first use in this function)
thr.c:55: error: (Each undeclared identifier is reported only once
thr.c:55: error: for each function it appears in.)
thr.c:55: error: `JB_SP' undeclared (first use in this function)
thr.c:27: warning: unused parameter `attr'
thr.c: In function `other':
thr.c:86: warning: unused parameter `arg'

basically the same error message. So you must be defining 'JS_BP'
and 'JB_BP' in places you don't show. It's nowhere defined in the
code you posted (and I have no idea what they should be), so the
compiler is completely right in complaining. (BTW, there's no good
reason to cast the return value of malloc(), identifiers starting
with an underscore are reserved for the implementation, your type-
def of 'othread_attr_t' looks mysterious (a structure with no
members), your casts look very strange to say the least (int's and
pointers may have different sizes), and lots more of things that
make no sense at all). What that's all supposed to do?

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #2

P: n/a
In article <3a*************@uni-berlin.de>,
<Je***********@physik.fu-berlin.de> wrote:
:basically the same error message. So you must be defining 'JS_BP'
:and 'JB_BP' in places you don't show. It's nowhere defined in the
:code you posted (and I have no idea what they should be),

They appear to be in <setjmp.h> at least on some systems.

My copy of the standard is packed at the moment, so I can't check
to see whether the standard has anything to say about what the
interior structure of a jump buffer is.
--
Feep if you love VT-52's.
Nov 14 '05 #3

P: n/a
JS
On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
JS <sf****@asdas.com> wrote:

<lots of cde snipped>
The error I get is:

56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
make H:\thread\make *** [thread.o] Error 1

when I compile the same code on Linux it works fine! But I am sure that I
use Cygwin so that should be as good as using Linux.


No, it doesn't compile, not even on Linux. I just took your code
and tried to compile it (under Linux) and, voila,

thr.c:55: error: `JB_BP' undeclared (first use in this function)
thr.c:55: error: (Each undeclared identifier is reported only once
thr.c:55: error: for each function it appears in.)
thr.c:55: error: `JB_SP' undeclared (first use in this function)
thr.c:27: warning: unused parameter `attr'
thr.c: In function `other':
thr.c:86: warning: unused parameter `arg'

basically the same error message. So you must be defining 'JS_BP'
and 'JB_BP' in places you don't show. It's nowhere defined in the
code you posted (and I have no idea what they should be), so the
compiler is completely right in complaining. (BTW, there's no good
reason to cast the return value of malloc(), identifiers starting
with an underscore are reserved for the implementation, your type-
def of 'othread_attr_t' looks mysterious (a structure with no
members), your casts look very strange to say the least (int's and
pointers may have different sizes), and lots more of things that
make no sense at all). What that's all supposed to do?

Regards, Jens

Well it compiles fine on my Ubuntu Linux....

Nov 14 '05 #4

P: n/a
JS <as*@asd.com> wrote:
On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
JS <sf****@asdas.com> wrote:

<lots of cde snipped>
The error I get is:

56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
make H:\thread\make *** [thread.o] Error 1

when I compile the same code on Linux it works fine! But I am sure that I
use Cygwin so that should be as good as using Linux.


No, it doesn't compile, not even on Linux. I just took your code
and tried to compile it (under Linux) and, voila,

thr.c:55: error: `JB_BP' undeclared (first use in this function)
thr.c:55: error: (Each undeclared identifier is reported only once
thr.c:55: error: for each function it appears in.)
thr.c:55: error: `JB_SP' undeclared (first use in this function)
thr.c:27: warning: unused parameter `attr'
thr.c: In function `other':
thr.c:86: warning: unused parameter `arg'

basically the same error message. So you must be defining 'JS_BP'
and 'JB_BP' in places you don't show. It's nowhere defined in the

Well it compiles fine on my Ubuntu Linux....


But not in standard compliant mode - unless you ask for that you get
lots of non-portable extensions included - and you can't expect them
to exist on a completely different type of system. If you search the
C89 or C99 standard you won't find the string "JB" anywhere. If you
want to check compile with at least the options '-ansi -pedantic' -
normally gcc is far from standard compliant (and even in the POSIX
standard I didn't find anything about 'JB_[A-Z]P' when looking up
setjmp() and things related to it). And while 'JB_SP' and 'JB_BP'
seem to be defined somewhere in the innards for setjmp() on IA32
Linux I only found 'JB_SP' in a header file for IRIX or OSF1, but not
'JB_BP'. There are no guarantees at all, at least from the C standard,
when you start to mess around with the innards of a 'jmp_buf' variable
- what's stored there and where and in what format is as system-depen-
dent as you can get.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #5

P: n/a
JS
> > Well it compiles fine on my Ubuntu Linux....

But not in standard compliant mode - unless you ask for that you get
lots of non-portable extensions included - and you can't expect them
to exist on a completely different type of system. If you search the
C89 or C99 standard you won't find the string "JB" anywhere. If you
want to check compile with at least the options '-ansi -pedantic' -
normally gcc is far from standard compliant (and even in the POSIX
standard I didn't find anything about 'JB_[A-Z]P' when looking up
setjmp() and things related to it). And while 'JB_SP' and 'JB_BP'
seem to be defined somewhere in the innards for setjmp() on IA32
Linux I only found 'JB_SP' in a header file for IRIX or OSF1, but not
'JB_BP'. There are no guarantees at all, at least from the C standard,
when you start to mess around with the innards of a 'jmp_buf' variable
- what's stored there and where and in what format is as system-depen-
dent as you can get.

But how can it be that you get the error messages and I don't get them in
Ubuntu Linux, is it because I don't compile with the right commands? I am a
bit concerned that my compiler don't detect the errors, when your compiler
does...
Nov 14 '05 #6

P: n/a
JS wrote:
Well it compiles fine on my Ubuntu Linux....
But not in standard compliant mode - unless you ask for that you get
lots of non-portable extensions included - and you can't expect them
to exist on a completely different type of system. If you search the
C89 or C99 standard you won't find the string "JB" anywhere. If you
want to check compile with at least the options '-ansi -pedantic' - ^^^^^^^^^^^^^^^normally gcc is far from standard compliant (and even in the POSIX


<snip>
But how can it be that you get the error messages and I don't get them in
Ubuntu Linux, is it because I don't compile with the right commands? I am a
bit concerned that my compiler don't detect the errors, when your compiler
does...


As stated above in the text you quoted, use the '-ansi -pedantic'
options on gcc.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #7

P: n/a
Flash Gordon wrote:
JS wrote:

<snip>
But how can it be that you get the error messages and I don't get
them in Ubuntu Linux, is it because I don't compile with the right
commands? I am a bit concerned that my compiler don't detect the
errors, when your compiler does...


As stated above in the text you quoted, use the '-ansi -pedantic'
options on gcc.


Also include -W -Wall.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #8

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Flash Gordon wrote:
JS wrote:

<snip>
But how can it be that you get the error messages and I don't get
them in Ubuntu Linux, is it because I don't compile with the right
commands? I am a bit concerned that my compiler don't detect the
errors, when your compiler does...


As stated above in the text you quoted, use the '-ansi -pedantic'
options on gcc.


Also include -W -Wall.


There's been some debate about whether "-W -Wall" is as useful as it
should be (some of the warnings may be questionable), but at worst
you'll get too many warnings, which is probably better than too few.
You just have to know which ones to ignore.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #9

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
In article <3a*************@uni-berlin.de>,
<Je***********@physik.fu-berlin.de> wrote:
:basically the same error message. So you must be defining 'JS_BP'
:and 'JB_BP' in places you don't show. It's nowhere defined in the
:code you posted (and I have no idea what they should be),

They appear to be in <setjmp.h> at least on some systems.


Then some systems are broken; those identifiers are the programmer's,
not the implementation's.

Richard
Nov 14 '05 #10

P: n/a
JS
On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
JS <sf****@asdas.com> wrote:

<lots of cde snipped>
The error I get is:

56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
make H:\thread\make *** [thread.o] Error 1

when I compile the same code on Linux it works fine! But I am sure that I
use Cygwin so that should be as good as using Linux.


No, it doesn't compile, not even on Linux. I just took your code
and tried to compile it (under Linux) and, voila,

thr.c:55: error: `JB_BP' undeclared (first use in this function)
thr.c:55: error: (Each undeclared identifier is reported only once
thr.c:55: error: for each function it appears in.)
thr.c:55: error: `JB_SP' undeclared (first use in this function)
thr.c:27: warning: unused parameter `attr'
thr.c: In function `other':
thr.c:86: warning: unused parameter `arg'

basically the same error message. So you must be defining 'JS_BP'
and 'JB_BP' in places you don't show. It's nowhere defined in the
code you posted (and I have no idea what they should be), so the
compiler is completely right in complaining. (BTW, there's no good
reason to cast the return value of malloc(), identifiers starting
with an underscore are reserved for the implementation, your type-
def of 'othread_attr_t' looks mysterious (a structure with no
members), your casts look very strange to say the least (int's and
pointers may have different sizes), and lots more of things that
make no sense at all). What that's all supposed to do?

Regards, Jens

I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits

So I guess that is why it compiles and runs as it should on my Ubuntu
Linux. But for some reason theses definitions are not in Cygwin.

Nov 14 '05 #11

P: n/a
On Fri, 25 Mar 2005 15:57:29 +0100, JS
<as*@asd.com> wrote:
On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:

I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits
Well, it's a violation of the C standard if that file gets included when
you write #include <setjmp.h> (or any other standard header), since
those names are not defined by the standard and are in the "user"
namespace (they don't start with _ or one of the other prefixes). A
strictly conforming program is free to declare JS_BP or JB_BP, and that
would break on your system.
So I guess that is why it compiles and runs as it should on my Ubuntu
Linux. But for some reason theses definitions are not in Cygwin.


Because the Cygwin library doesn't need them? Because the Cygwin
library uses correct naming conventions for its implementation-specific
names? They aren't in the C standard, so if you find them on some
system without including a non-standard header they are incorrect (if
you include a non-standard header (like "sys/types.h") then anything you
find is implementation specific).

As others have said, there is no portable way of accessing anything in a
jmp_buf. The type is intentionally opaque to the user, the only thing
known about it is that it is implemented as an array (that's how you can
write setjmp(fred) instead of setjmp(&fred)), but that could be an aray
of char, array of int, an array with only one member where that is a
struct, or whatever.

Chris C
Nov 14 '05 #12

P: n/a
JS <as*@asd.com> writes:
On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
JS <sf****@asdas.com> wrote:
<lots of cde snipped>
The error I get is:
56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

[snip] I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits

So I guess that is why it compiles and runs as it should on my Ubuntu
Linux. But for some reason theses definitions are not in Cygwin.


There's no reason they should be.

In fact, if the compiler is invoked in conforming mode, those
identifiers should not be visible to any program that uses only
standard headers.

Based on an experiment I just tried on one of my own Linux systems,
your code compiles without error using gcc with default options. "gcc
-ansi" complains (correctly) that JS_BP and JB_BP are undeclared. And
on my Cygwin system, those identifiers are not available at all.

Apparently in the non-conforming mode that is gcc's default, these
identifiers are provided to allow access to the internals of a
jmp_buf. The price paid for this is that an otherwise conforming
program that attempts to use these identifiers for itself will fail to
compile -- and a program that uses the system-defined JS_BP and JB_BP
will be non-portable. In conforming ("-ansi") mode, the identifiers
are hidden, allowing the program to use them as it chooses.

A portable program cannot do anything that depends on the internal
details of a jmp_buf, beyond the standard's guarantee that it's an
array type. As you've seen, it appears that a Cygwin jmp_buf has
different internals than a Linux jmp_buf (or at least the Cygwin
headers don't expose them the same way).

You can write Linux-specific code that depends on the internals of a
Linux-specific jmp_buf. Or you can write Cygwin-specific code that
depends on the internals of a Cygwin-specific jmp_buf. (Likewise for
other systems.) Or you can write portable code that doesn't assume
anything beyond the fact that a jmp_buf is an array.

Porting your Linux-specific code to Cygwin will require some
non-trivial effort, if it's possible at all. We can't help you with
that here; your best resource is probably the Cygwin mailing lists.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.