undefined reference to cexpf, while cexpf not used anywhere in source

[MBeijer]

Why would the compiler turn this expression into cexpf?

projectilelib.o(.text+0x50e8): In function `projectile::move()':
projectilelib.cpp:772: undefined reference to `cexpf'

Row 772 in projectilelib.cpp:
float rad_angle = (angle * M_PI)/180.00;

Angle is a float, so is M_PI.

[bebbo]

please attach a preprocessed file!

[MBeijer]

https://www.eevul.net/downloads/projectilelib.o

…

On Tue, Apr 3, 2018 at 3:50 PM, bebbo ***@***.***> wrote: please attach a preprocessed file! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIXahYOngwdNnmFHgKahgYsVewCJPGogks5tk34NgaJpZM4TFFST> .

[MBeijer]

I've since updated the source, it's now referring to line 794 (same code though)

[MBeijer]

changing the float to a double removes the cexpf reference, and I narrowed it down to have something to do with these lines:

        position.x = _speed_x*cos(rad_angle) + position0.x;
        position.y = _speed_x*sin(rad_angle) + position0.y;

float + cos / sin = complex or something like that.

[bebbo]

the call to cexpf is ok, since the code contains:

        position.x = _speed_x*cos(rad_angle) + position0.x;
        position.y = _speed_x*sin(rad_angle) + position0.y;

If sin and cos of the same angle is calculated, the cexpf function calculates both in one call.

[MBeijer]

But still, cexpf is not defined anywhere in libm etc, so it poses a dilemma.

[bebbo]

cexpf is one of the complex functions.

[MBeijer]

Yeah, but the complex functions seem to be missing from the toolchain altogether, hence the undefined reference. I solved it for now by changing over to double.

[bebbo]

I know, and you knew it too: bebbo/amigaos-cross-toolchain#68

I'll grab a fork of libnix and apply changes to it. Will do a pull request when I'm done. :)

[MBeijer]

Oh, derp, yes. Completely forgot about this. I've been pretty busy switching jobs and traveling.

[MBeijer]

And I think it was actually more complex to add than I thought. No pun intended. Either way, it's above what I can do at the moment

[bebbo]

extern float cosf(float);
extern float sinf(float);
extern float expf(float);

#define complex _Complex

#define REALPART(z) (__real__(z))
#define IMAGPART(z) (__imag__(z))
#define COMPLEX_ASSIGN(z_, r_, i_) {__real__(z_) = (r_); __imag__(z_) = (i_);}


/* exp(z) = exp(a)*(cos(b) + i sin(b))  */
#if !defined(HAVE_CEXPF)
#define HAVE_CEXPF 1
float complex cexpf (float complex z);

float complex
cexpf (float complex z)
{
  float a, b;
  float complex v;

  a = REALPART (z);
  b = IMAGPART (z);
  COMPLEX_ASSIGN (v, cosf (b), sinf (b));
  return expf (a) * v;
}
#endif

[bebbo]

the sad part: with this code there is no benefit from using cexpf...

[bebbo]

added libcomplex.a => use -lcomplex to use those functions

[bebbo]

removed libcomplex.a - adding all complex stuff to libm.a

[th-otto]

Seems to be already solved. but i just stumbled upon this.

I once had a similar problem when porting the Atari toolchain. As with the amiga library, the c-library of atari is missing the complex functions. The solution was to add an

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

in the target configuration header (gcc/config/m68k/mint.h in my case). For some reason, the optimizer turns a sequence of sin/cos calls into a call to cexp(), and at a later point changes that to a call to sincos(). But if you don't set the above symbol, the library call to cexp() will remain, resulting in an unresolved external.