Failure to build cone-0.69 on Mac OS X: 'mvaddwstr' was not declared in this scope

View: New views
3 Messages — Rating Filter:   Alert me  

Parent Message unknown Failure to build cone-0.69 on Mac OS X: 'mvaddwstr' was not declared in this scope

by Boey Maun Suang :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi there,

I'm trying to write a MacPorts port for cone, but I haven't yet been  
able to get it to build.  I managed to fix one error with the  
attached patch file (though you might find a better way of fixing  
it); I unfortunately didn't keep the log of what that error was (it  
was so long ago that I did that patch), but I assume that it was for  
an undefined symbol.  (If you'd like, I'll rebuild it again without  
the patch to get the error log for you, but not tonight; I should  
have been asleep ages ago.)

However, even with that patch in place, it terminates with the  
following output:

OS: Mac OS X 10.4.9
Architecture: Intel Core Duo

<snip>
Making all in curses
make  all-am
Compiling curses.C
Compiling cursesbutton.C
Compiling curseschoicebutton.C
Compiling cursescontainer.C
Compiling cursesdialog.C
Compiling cursesfield.C
Compiling cursesfilereq.C
Compiling curseskeyhandler.C
Compiling curseslabel.C
Compiling cursesmainscreen.C
Compiling cursesmultilinelabel.C
Compiling cursesmoronize.C
Compiling cursesobject.C
Compiling cursesscreen.C
cursesscreen.C: In member function 'virtual bool  
CursesScreen::writeText(const wchar_t*, int, int, const  
Curses::CursesAttr&) const':
cursesscreen.C:276: error: 'mvaddwstr' was not declared in this scope
make[3]: *** [cursesscreen.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
</snip>

I can provide a full output log of the configure and build steps if  
anyone thinks it would be useful.

Any suggestions that you might have as to how I might get this to  
work would be most appreciated; I'm really out of my depth with this  
error.

Kind regards,


Maun Suang

P.S.  Incidentally, is there a reason for running configure  
separately in each subdirectory, and is there a way of caching  
results from one subdirectory to be used in another?  For me, the  
configure stage seems to take at least as long as the build stage (up  
to the failure point).

P.P.S.  I just noticed that configure is not finding aspell, despite  
the aspell binary being installed at /opt/local/bin just like the  
perl binary, which it does find.  Any ideas on this as well?

--
Boey Maun Suang (Boey is my surname)
Mobile: +61 403 855 677
Email: boeyms@...



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-cone mailing list
Courier-cone@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone

patch-rfc1035_rfc1035_res.h (310 bytes) Download Attachment

Re: Failure to build cone-0.69 on Mac OS X: 'mvaddwstr' was not declared in this scope

by Sam Varshavchik :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Boey Maun Suang writes:

> Hi there,
>
> I'm trying to write a MacPorts port for cone, but I haven't yet been  
> able to get it to build.  I managed to fix one error with the  
> attached patch file (though you might find a better way of fixing  

The code is correct.  The object in question is defined in rfc1035_res.c,
which is included in the ar library that's being linked against.

I recall that this is a known, longstanding issue with OSX's linker which
fails to resolve non-functional external objects.  You might want to
consider looking into the BSD ports to see what they do to work around it.
OSX's and BSD's linker share a common history, and a common set of bugs.

> However, even with that patch in place, it terminates with the  
> following output:
>

> Compiling cursesscreen.C
> cursesscreen.C: In member function 'virtual bool  
> CursesScreen::writeText(const wchar_t*, int, int, const  
> Curses::CursesAttr&) const':
> cursesscreen.C:276: error: 'mvaddwstr' was not declared in this scope

mvwaddstr should be declared in /usr/include/curses.h

Having said that: Cone checks if your curses supports wide characters; if so
it reads /usr/include/ncursesw/curses.h, if that's the case.  This
particular code fragment uses the wide character curses code; you'll need to
check what's declared in your ncursesw/curses.h

> P.S.  Incidentally, is there a reason for running configure  
> separately in each subdirectory, and is there a way of caching  
> results from one subdirectory to be used in another?  For me, the  

-C option to the configure script enables some caching.

> configure stage seems to take at least as long as the build stage (up  
> to the failure point).
>
> P.P.S.  I just noticed that configure is not finding aspell, despite  
> the aspell binary being installed at /opt/local/bin just like the  
> perl binary, which it does find.  Any ideas on this as well?

Cone does not use the aspell binary, it links against the aspell library
directly.  You need to have libaspell.so installed, as well as aspell's
header files in /usr/include/aspell




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-cone mailing list
Courier-cone@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone

attachment0 (196 bytes) Download Attachment

Re: Failure to build cone-0.69 on Mac OS X: 'mvaddwstr' was not declared in this scope

by Boey Maun Suang :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 16/04/2007, at 04:05, Sam Varshavchik wrote:

> he code is correct.  The object in question is defined in  
> rfc1035_res.c, which is included in the ar library that's being  
> linked against.
>
> I recall that this is a known, longstanding issue with OSX's linker  
> which fails to resolve non-functional external objects.  You might  
> want to consider looking into the BSD ports to see what they do to  
> work around it. OSX's and BSD's linker share a common history, and  
> a common set of bugs.

I realised that the code was correct and that it was an OS X linker  
bug (I've had to work around some other ones in other ports) -- sorry  
for not making that clear -- but it would probably be worth patching  
the relevant file with some "#if defined(__APPLE__) || defined
(__MACOS__)" encapsulation or similar for whatever the workaround  
proves to be.  I haven't yet found anyone documenting such a bug, but  
I'm still looking.

> mvwaddstr should be declared in /usr/include/curses.h
>
> Having said that: Cone checks if your curses supports wide  
> characters; if so it reads /usr/include/ncursesw/curses.h, if  
> that's the case.  This particular code fragment uses the wide  
> character curses code; you'll need to check what's declared in your  
> ncursesw/curses.h

Both /usr/include/curses.h (from the system (Mac OS X 10.4.9)) and /
opt/local/include/ncursesw/curses.h (from the wide character MacPorts  
installation of ncurses-5.6) contain:

#define mvwaddstr(win,y,x,str)          (wmove(win,y,x) == ERR ?  
ERR : waddnstr(win,str,-1))

and it wasn't fixed by adding CPPFLAGS='-I/opt/local/include'  
LDFLAGS='-L/opt/local/lib' to the environment (configure had already  
had --prefix=/opt/local as an argument).  I'm happy to give you any  
further information that you might find useful, but I'm currently at  
a loss for ideas on how to fix this.

> -C option to the configure script enables some caching.

Ah, somehow I hadn't noticed the existence of that flag; it runs much  
faster.  Thanks!

> Cone does not use the aspell binary, it links against the aspell  
> library directly.  You need to have libaspell.so installed, as well  
> as aspell's header files in /usr/include/aspell

Setting CPPFLAGS and LDFLAGS fixed this one; sorry about that.

Kind regards,


Maun Suang

--
Boey Maun Suang (Boey is my surname)
Mobile: +61 403 855 677
Email: boeyms@...



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-cone mailing list
Courier-cone@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone
LightInTheBox - Buy quality products at wholesale price!