Quantcast

two comilation errors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

two comilation errors

Richard Kim-2

I use SPARC IPC, SunOS 4.1.1, X11R5
        gcc-2.3.3
        octave-0.67 (patched from 0.66 to 0.67)


First, an error with src/lex.cc:

g++ -O -g -Wall  -I. -I./../liboctave -I./.. -I. -I../liboctave -I.. -DNPSOL_MISSING=1 -DQPSOL_MISSING=1 -DFSQP_MISSING=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -DRETSIGTYPE=void -DHAVE_TERMIO_H=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_IEEE_MATH=1  -DUNIXPLOT=1 -DF77_APPEND_UNDERSCORE=1                   -c lex.cc -o lex.o
In file included from /usr/local/lib/g++-include/std.h:25, from /usr/local/lib/g++-include/osfcn.h:5, from lex.cc:35:
/usr/local/lib/g++-include/stdlib.h:35: declaration of `void  free (void *)' with different language linkage
lex.cc:14: previous declaration here
lex.l:396: warning: `yy_last_accepting_state' defined but not used
lex.l:396: warning: `yy_last_accepting_cpos' defined but not used
gmake[1]: *** [lex.o] Error 1


I tried commenting out the offending line in src/lex.cc:

        /* void free( void* );  -rk2/11/93 3:35pm. */

This gets rid of the above error.


Second, while linking "src/octave", the loader gives the following error:

ld: Undefined symbol
   _malloc__FUi


What is wrong?

Richard Y. Kim (503) 627-2375 (Office)
[hidden email] (503) 627-1707 (Fax)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: two comilation errors

John Fletcher-7
> Date:       Thu, 11 Feb 93 18:03:11 PST
> From:       [hidden email] (Richard Kim)
> To:         Octave List <[hidden email]>
> Cc:         [hidden email]
> Subject:    two comilation errors

>
> I use SPARC IPC, SunOS 4.1.1, X11R5
>   gcc-2.3.3
>   octave-0.67 (patched from 0.66 to 0.67)
>
<first problem deleted>
>
>
> Second, while linking "src/octave", the loader gives the following error:
>
> ld: Undefined symbol
>    _malloc__FUi
>
This looks to me that malloc is being treated as a C++ routine rather
than a C routine, hence the mangled name.  I guess that is a header
problem.  The header should have  extern "C" put round it in C++
context.
>
> What is wrong?
>
> Richard Y. Kim            (503) 627-2375 (Office)
> [hidden email]     (503) 627-1707 (Fax)
>
I hope this helps.

John

---------------------------------------------------------------------
Dr John P. Fletcher
Department of Chemical Engineering and Applied Chemistry,
Aston University,         Tel: (44) 21 359 3611 ext 4625
Aston Triangle,         Email(Most systems): [hidden email]
BIRMINGHAM B4 7ET  U.K.   Email(JANET only): [hidden email]
---------------------------------------------------------------------

Loading...