undefined symbol sincos

[joukj]

Hi all,

when compiling a C-program, which works flawless on Alpha/Itanium, I get on X86-64 an undefined symbol sincos while linking. I compiled everything with /list/show=all, but cannot find any mention of sincos in the resulting lis files. What am I missing and what causes this?

I'm using:
VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 E9.2-1

on Linux sincos is defined as a function which calculates both sin & cos. Is this function missing somewhere? (but where?)

[hb]

It is difficult to help without more information. What are the linker messages? Can you share the source code?

I would check the object module that the linker shows in its message(s). I would use ANALYZE's disassembler to create a machine code listing. The undefined symbol should show up in the listing with a reference to the source line. This should point you to the C code that generates the reference.

[joukj]

Hi,

I can share the source code. It is ImageMagick. But compiling that needs you to have many depending packeges.

I did the ana/obj draw.obj/disa/out=draw.dis

Anylizing the draw.dis file gives me one entry with sincos:

callq sincos@PLT

I think the @PLT is added because it is expected in a CRTL library.
The callq to a routine that includes many sin and cos calls to the same argument.
I tried to compile the routines with /noop, which solves the problem

hmm I smell a bug

[hb]

I did the ana/obj draw.obj/disa/out=draw.dis

Anylizing the draw.dis file gives me one entry with sincos:

callq sincos@PLT

I think the @PLT is added because it is expected in a CRTL library.
The callq to a routine that includes many sin and cos calls to the same argument.
I tried to compile the routines with /noop, which solves the problem

hmm I smell a bug

The @PLT (Procedure Linkage Table) is used to make a call to an external procedure (external to your source module). The CRTL names have a prefix DECC$ or MATH$ in case of a math function. And the compiler knows these and adds the prefix. Sincos is a known name, otherwise it would have such a prefix.

I suspect sincos is defined in another module/shareable image within ImageMagick or any package it depends on.

I would double check with the same ANALYZE command and see if that "callq" changed. I expect that it didn't. I would create a linker map with cross references and check for the working case from where sincos is resolved.

[mjvms27]

Note that sincos(), is a GNU extension to the standard math library and on Linux the reference would resolve in glibc itself, but unlikely to resolve on a platform that isn't offering the actual glibc library underneath, or offering a similar replacement.

https://www.gnu.org/software/gnulib/man ... 002eh.html

[jonesd]

Note that sincos(), is a GNU extension to the standard math library and on Linux the reference would resolve in glibc itself, but unlikely to resolve on a platform that isn't offering the actual glibc library underneath.[/url]

Since calling sin(x) and cos(x) in the same statement or nearby statements is such a common pattern, I've see compilers that recognize it and replace those calls with an optimized sincos function.

[mjvms27]

I'm not certain, but you might be able to get away with just creating a vmssincos.c and including it in the link.

Code: Select all

/* vmssincos.c */
#include <math.h>

void sincos(double x, double *psin, double *pcos)
{
    *psin = sin(x);
    *pcos = cos(x);
}

[arne_v]

If I understand it correct then:
- the code builds on Alpha and Itanium but give this error on x86-64
- this function is not expected to be on any VMS version because it is glibc specific

This makes me guess that we have something like:

#if windows
// use something else than sincos
#elif VMS alpha or VMS Itanium
// use something else than sincos
#else
// assume glibc and use sincos
#endif

and there is a need to change the #if logic to treat VMS x64 like VMS Alpha and VMS Itanium.

[jreagan]

That is the LLVM optimizer combining a sin and a cos together. I thought we had fixed the prefix name in the internal table. Must have missed one.