Ð’ Sun, 6 Jun 2010 16:38:43 +0200
Lukáš Jirkovský <l.jirkovsky@gmail.com> пишет:

LJ> Hello everyone,
LJ> recently I've a problem building rawstudio-svn on x86_64.
LJ> Unfortunately it seems that the problem doesn't lie in the rawstudio
LJ> itself, because I'm not able to build any older revision which I was
LJ> able to build before.
LJ>
LJ> The error is:
LJ> application.c: In function ‘segfault_sigaction’:
LJ> application.c:599:56: error: ‘REG_RIP’ undeclared (first use in this function)
LJ> application.c:599:56: note: each undeclared identifier is reported
LJ> only once for each function it appears in
LJ> application.c:617:44: error: ‘REG_RAX’ undeclared (first use in this function)
LJ> application.c:619:30: error: ‘REG_RBX’ undeclared (first use in this function)
LJ> application.c:621:30: error: ‘REG_RCX’ undeclared (first use in this function)
LJ> application.c:623:30: error: ‘REG_RDX’ undeclared (first use in this function)
LJ> application.c:625:30: error: ‘REG_RSI’ undeclared (first use in this function)
LJ> application.c:627:30: error: ‘REG_RDI’ undeclared (first use in this function)
LJ> application.c:629:30: error: ‘REG_R8’ undeclared (first use in this function)
LJ> application.c:631:30: error: ‘REG_R9’ undeclared (first use in this function)
LJ> application.c:633:30: error: ‘REG_R10’ undeclared (first use in this function)
LJ> application.c:635:30: error: ‘REG_R11’ undeclared (first use in this function)
LJ> application.c:637:30: error: ‘REG_R12’ undeclared (first use in this function)
LJ> application.c:639:30: error: ‘REG_R13’ undeclared (first use in this function)
LJ> application.c:641:30: error: ‘REG_R14’ undeclared (first use in this function)
LJ> application.c:643:30: error: ‘REG_R15’ undeclared (first use in this function)
LJ> application.c:645:30: error: ‘REG_RSP’ undeclared (first use in this function)
LJ>
LJ> I did a grep on /usr/include and /usr/lib but nothing defines any of
LJ> these. My guess is that the problem may be caused by a new gcc. I
LJ> should note I already searched on google but without any success (most
LJ> results were saying that instead of REG_EIP, REG_EAX and others the
LJ> REG_RIP etc. should be used on 64bit systems).
LJ>
LJ> What do you think where is the source of the problem?
LJ>

On my 64bit this macros defined in /usr/include/sys/ucontext.h

Try at the top of source.c add:
#define __USE_GNU
#include <sys/ucontext.h>

--
WBR
Alexander Drozdov
FIDO: 2:5045/41.84
Site: http://hatred.homelinux.net
Site: http://archlinux.org.ru

On 6 June 2010 17:32, Alexander 'hatred' Drozdoff <adrozdoff@gmail.com> wrote:
>
> On my 64bit this macros defined in /usr/include/sys/ucontext.h
>
> Try at the top of source.c add:
> #define __USE_GNU
> #include <sys/ucontext.h>
>
> --
> WBR
> Alexander Drozdov
> FIDO: 2:5045/41.84
> Site: http://hatred.homelinux.net
> Site: http://archlinux.org.ru
>

Hi Alexander,
the code you suggest is already here but it doesn't work.

To be honest I didn't look into the ucontext.h code before so I
interpreted the results grep returned as making an alias to the
already defined name. The enum defined in ucontext.h looks functional
so I don't have any idea what's going on.

2010/6/6 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
> On 6 June 2010 17:32, Alexander 'hatred' Drozdoff <adrozdoff@gmail.com> wrote:
>>
>> On my 64bit this macros defined in /usr/include/sys/ucontext.h
>>
>> Try at the top of source.c add:
>> #define __USE_GNU
>> #include <sys/ucontext.h>
>>
>> --
>> WBR
>> Alexander Drozdov
>> FIDO: 2:5045/41.84
>> Site: http://hatred.homelinux.net
>> Site: http://archlinux.org.ru
>>
>
> Hi Alexander,
> the code you suggest is already here but it doesn't work.
>
> To be honest I didn't look into the ucontext.h code before so I
> interpreted the results grep returned as making an alias to the
> already defined name. The enum defined in ucontext.h looks functional
> so I don't have any idea what's going on.
>

Oh, now I see where the problem is. There are several includes named ucontext.h

Lukas

>>
>
> Oh, now I see where the problem is. There are several includes named ucontext.h
>
> Lukas
>

OK, that's not the problem. I tried compiling it with -save-temps
option passed to gcc and I see that the correct file is included but
for some reason the #ifdef __USE_GNU part is not included even though
__USE_GNU is defined before #include <ucontext.h>

Any ideas?

2010/6/6 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
>>>
>>
>> Oh, now I see where the problem is. There are several includes named ucontext.h
>>
>> Lukas
>>
>
> OK, that's not the problem. I tried compiling it with -save-temps
> option passed to gcc and I see that the correct file is included but
> for some reason the #ifdef __USE_GNU part is not included even though
> __USE_GNU is defined before #include <ucontext.h>
>
> Any ideas?
>

Anyway, if I copy the part

#ifdef __USE_GNU
/* Number of each register in the `gregset_t' array. */
enum
{
REG_R8 = 0,
# define REG_R8 REG_R8
…
# define REG_CR2 REG_CR2
};
#endif

from the sys/ucontext.h to another file the enum is included correctly
and application.c compiles.

On 6 June 2010 18:21, Alexander 'hatred' Drozdoff <adrozdoff@gmail.com> wrote:
> Ð’ Sun, 6 Jun 2010 18:06:26 +0200
> Lukáš Jirkovský <l.jirkovsky@gmail.com> пишет:
>
> LJ> 2010/6/6 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
> LJ> >>>
> LJ> >>
> LJ> >> Oh, now I see where the problem is. There are several includes named ucontext.h
> LJ> >>
> LJ> >> Lukas
> LJ> >>
> LJ> >
> LJ> > OK, that's not the problem. I tried compiling it with -save-temps
> LJ> > option passed to gcc and I see that the correct file is included but
> LJ> > for some reason the #ifdef __USE_GNU part is not included even though
> LJ> > __USE_GNU is defined before #include <ucontext.h>
> LJ> >
> LJ> > Any ideas?
> LJ> >
> LJ>
> LJ> Anyway, if I copy the part
> LJ>
> LJ> #ifdef __USE_GNU
> LJ> /* Number of each register in the `gregset_t' array. Â**/
> LJ> enum
> LJ> {
> LJ> Â* REG_R8 = 0,
> LJ> # define REG_R8 Â* Â* REG_R8
> LJ> …
> LJ> # define REG_CR2 Â* Â*REG_CR2
> LJ> };
> LJ> #endif
> LJ>
> LJ> from the sys/ucontext.h to another file the enum is included correctly
> LJ> and application.c compiles.
>
> Oh... Add to CFLAGS next parameter:
> -D__USE_GNU
>
> --
> WBR
> Alexander Drozdov
> FIDO: 2:5045/41.84
> Site: http://hatred.homelinux.net
> Site: http://archlinux.org.ru
>

I already tried that but it doesn't work either.

Lukas

Ð’ Sun, 6 Jun 2010 17:52:49 +0200
Lukáš Jirkovský <l.jirkovsky@gmail.com> пишет:

LJ> >>
LJ> >
LJ> > Oh, now I see where the problem is. There are several includes named ucontext.h
LJ> >
LJ> > Lukas
LJ> >
LJ>
LJ> OK, that's not the problem. I tried compiling it with -save-temps
LJ> option passed to gcc and I see that the correct file is included but
LJ> for some reason the #ifdef __USE_GNU part is not included even though
LJ> __USE_GNU is defined before #include <ucontext.h>
LJ>
LJ> Any ideas?

I will try to build tomorrow. Looks like gcc touble.

--
WBR
Alexander Drozdov
FIDO: 2:5045/41.84
Site: http://hatred.homelinux.net
Site: http://archlinux.org.ru

Ð’ Sun, 6 Jun 2010 18:06:26 +0200
Lukáš Jirkovský <l.jirkovsky@gmail.com> пишет:

LJ> 2010/6/6 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
LJ> >>>
LJ> >>
LJ> >> Oh, now I see where the problem is. There are several includes named ucontext.h
LJ> >>
LJ> >> Lukas
LJ> >>
LJ> >
LJ> > OK, that's not the problem. I tried compiling it with -save-temps
LJ> > option passed to gcc and I see that the correct file is included but
LJ> > for some reason the #ifdef __USE_GNU part is not included even though
LJ> > __USE_GNU is defined before #include <ucontext.h>
LJ> >
LJ> > Any ideas?
LJ> >
LJ>
LJ> Anyway, if I copy the part
LJ>
LJ> #ifdef __USE_GNU
LJ> /* Number of each register in the `gregset_t' array. */
LJ> enum
LJ> {
LJ> REG_R8 = 0,
LJ> # define REG_R8 REG_R8
LJ> …
LJ> # define REG_CR2 REG_CR2
LJ> };
LJ> #endif
LJ>
LJ> from the sys/ucontext.h to another file the enum is included correctly
LJ> and application.c compiles.

Oh... Add to CFLAGS next parameter:
-D__USE_GNU

--
WBR
Alexander Drozdov
FIDO: 2:5045/41.84
Site: http://hatred.homelinux.net
Site: http://archlinux.org.ru

With this (rather ugly) patch it compiles. I don't see a difference
between using this and ucontext.h only…

Lukas

I still see the problem. Is it possible that it's bug in GCC?

Lukas