Forum: GNU Radio Build failure - caused by posix_memalign.cc - in trunk built under Cygwin

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Prior-Jones, Michael R (Guest)
on 2009-02-17 15:50
(Received via mailing list)
Hi,

I'm trying to build the current trunk version of Gnuradio under Cygwin
on Windows XP. Make currently fails with

posix_memalign.cc: In function `int posix_memalign(void**, size_t,
size_t)':
posix_memalign.cc:86: error: `valloc' undeclared (first use this
function)
posix_memalign.cc:86: error: (Each undeclared identifier is reported
only once f
or each function it appears in.)

Have I missed something?

Thanks,

Mike
Michael D. (Guest)
on 2009-02-17 16:24
(Received via mailing list)
On Feb 17, 2009, at 8:48 AM, Prior-Jones, Michael R wrote:
> Have I missed something?
Hmmm.  We've tried to include headers in posix_memalign.cc which work
with all OSs (OSX, Linux, Cygwin, ?MinGW?) for valloc ()).  According
to the error the compiler was at line 86, which means that the macro
HAVE_VALLOC was defined, which means that 'configure' found the valloc
() function prototype somewhere -- but not in the header file(s)
included in posix_memalign.cc thus far.

If you issue (in a Cygwin terminal) "grep -lr valloc /usr/include" do
you get any files listed?  If so, what is it / are they?  Issuing this
instruction on Ubuntu 8.10 results in:

/usr/include/malloc.h
/usr/include/stdlib.h

So hopefully Cygwin uses one of these Linux headers to define the
valloc () function prototype.  stdlib.h is already included in
posix_memalign.cc, so it's probably not in that header.  Maybe
malloc.h?  We can easily put #if's around the #include to keep OSX
from barfing. - MLD
Prior-Jones, Michael R (Guest)
on 2009-02-17 16:31
(Received via mailing list)
>Hmmm.  We've tried to include headers in posix_memalign.cc which work
>with all OSs (OSX, Linux, Cygwin, ?MinGW?) for valloc ()).  According
>to the error the compiler was at line 86, which means that the macro
>HAVE_VALLOC was defined, which means that 'configure' found the valloc
>() function prototype somewhere -- but not in the header file(s)
>included in posix_memalign.cc thus far.

Thanks for your prompt reply. I'd guessed that something like that was
going on.

>If you issue (in a Cygwin terminal) "grep -lr valloc /usr/include" do
>you get any files listed?  If so, what is it / are they?  Issuing this
>instruction on Ubuntu 8.10 results in:
>
>/usr/include/malloc.h
>/usr/include/stdlib.h

What I get is:

/usr/include/cygwin/stdlib.h
/usr/include/cygwin/version.h
/usr/include/malloc.h

I'm guessing that /usr/include/cygwin/stdlib.h is the joker in the pack.

Mike
Michael D. (Guest)
on 2009-02-17 16:52
(Received via mailing list)
> What I get is:
>
> /usr/include/cygwin/stdlib.h
> /usr/include/cygwin/version.h
> /usr/include/malloc.h
>
> I'm guessing that /usr/include/cygwin/stdlib.h is the joker in the
> pack.

Can you figure out if /usr/include/cygwin/stdlib.h is #included from /
usr/include/malloc.h or /usr/include/stdlib.h or some other /usr/
include/[foo].h file?  I'd rather #include a reasonably standard
header file if at all possible. - MLD
Prior-Jones, Michael R (Guest)
on 2009-02-17 17:00
(Received via mailing list)
>Can you figure out if /usr/include/cygwin/stdlib.h is #included from /
>usr/include/malloc.h or /usr/include/stdlib.h or some other /usr/
>include/[foo].h file?  I'd rather #include a reasonably standard
>header file if at all possible. - MLD

/usr/include/stdlib.h references it:


#ifdef __CYGWIN__
#include <cygwin/stdlib.h>
#endif


MPJ
Don W. (Guest)
on 2009-02-17 17:23
(Received via mailing list)
----- Original Message -----
From: "Prior-Jones, Michael R" <removed_email_address@domain.invalid>
To: "Michael D." <removed_email_address@domain.invalid>
Cc: <removed_email_address@domain.invalid>
Sent: Tuesday, February 17, 2009 9:58 AM
Subject: RE: [Discuss-gnuradio] Build failure - caused by
posix_memalign.cc-
in trunk built under Cygwin


>#endif
/usr/include/cygwin/stdlib.h references valloc(), but valloc() is
declared
in /usr/include/malloc.h.  So <malloc.h> is what you want to include for
Cygwin.

-- Don W.
Michael D. (Guest)
on 2009-02-17 17:39
(Received via mailing list)
On Feb 17, 2009, at 10:22 AM, Don W. wrote:
> /usr/include/cygwin/stdlib.h references valloc(), but valloc() is
> declared in /usr/include/malloc.h.  So <malloc.h> is what you want
> to include for Cygwin.

Isn't <malloc.h> what was added in the first place to
posix_memalign.cc, which caused this issue?

I'm good with adding in malloc.h into configure.ac, then into
posix_memalign.cc with proper #ifdef around it.  That will work with
OSX, and won't hurt Linux, and sounds like it'll allow Cygwin to work.

Eric / Johnathan ... comments?  These are small / easy changes. - MLD
Don W. (Guest)
on 2009-02-17 18:14
(Received via mailing list)
----- Original Message -----
From: "Michael D." <removed_email_address@domain.invalid>
To: "Don W." <removed_email_address@domain.invalid>
Cc: "Prior-Jones, Michael R" <removed_email_address@domain.invalid>;
<removed_email_address@domain.invalid>
Sent: Tuesday, February 17, 2009 10:38 AM
Subject: Re: [Discuss-gnuradio] Build failure - caused by
posix_memalign.cc-
in trunk built under Cygwin


> On Feb 17, 2009, at 10:22 AM, Don W. wrote:
>> /usr/include/cygwin/stdlib.h references valloc(), but valloc() is
>> declared in /usr/include/malloc.h.  So <malloc.h> is what you want
>> to include for Cygwin.
>
> Isn't <malloc.h> what was added in the first place to
> posix_memalign.cc, which caused this issue?

No. What caused the issue is that valloc is not defined in the standard
place (<stdlib.h>) on Cygwin; <malloc.h> was added to fix the problem on
Cygwin, but it caused problems on other platforms.

> I'm good with adding in malloc.h into configure.ac, then into
> posix_memalign.cc with proper #ifdef around it.  That will work with
> OSX, and won't hurt Linux, and sounds like it'll allow Cygwin to work.
>
> Eric / Johnathan ... comments?  These are small / easy changes. - MLD

This sounds good to me as long as there is no hazard in including
<malloc.h>
on other (non-Cygwin) systems that have it but don't need it.

-- Don W.
This topic is locked and can not be replied to.