From @jhi

(as of blead 008e8e8)

Looks like some functions are defined as inline, but they are not there​:

jhi@​tru64​:t$ ../perl -I../lib porting/extrefs.t -v
1..1
cccmd = cc -o temp -c99 -no_ansi_alias -D_INTRINSICS -fprm d -ieee -trapuv -readonly_strings -D_SOCKADDR_LEN -D_POSIX_PII_SOCKET -I/usr/local/include/db3 -DLANGUAGE_C -I.. -DPERL_NO_INLINE_FUNCTIONS temp.c
cc​: Error​: ../proto.h, line 64​: The function "S__is_utf8_char_slow" has internal linkage, occurs in a context that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE STRLEN S__is_utf8_char_slow(const U8 *s, const U8 *e)
--------------------------------^
cc​: Error​: ../proto.h, line 161​: The function "S_append_utf8_from_native_byte" has internal linkage, occurs in a context that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE void S_append_utf8_from_native_byte(const U8 byte, U8** dest)
------------------------^
cc​: Error​: ../proto.h, line 285​: The function "S_av_top_index" has internal linkage, occurs in a context that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE SSize_t S_av_top_index(pTHX_ AV *av)
--------------------------------^
cc​: Error​: ../proto.h, line 1887​: The function "S_is_safe_syscall" has internal linkage, occurs in a context that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE bool S_is_safe_syscall(pTHX_ const char *pv, STRLEN len, const char *what, const char *op_name)
------------------------^
cc​: Error​: ../proto.h, line 4473​: The function "S_sv_only_taint_gmagic" has internal linkage, occurs in a context that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE bool S_sv_only_taint_gmagic(SV *sv)
------------------------^
not ok 1
# Failed test 1 - at porting/extrefs.t line 36

From @khwilliamson

On Mon Mar 30 15​:48​:01 2015, jhi wrote​:

(as of blead 008e8e8)

Looks like some functions are defined as inline, but they are not
there​:

jhi@​tru64​:t$ ../perl -I../lib porting/extrefs.t -v
1..1
cccmd = cc -o temp -c99 -no_ansi_alias -D_INTRINSICS -fprm d -ieee
-trapuv -readonly_strings -D_SOCKADDR_LEN -D_POSIX_PII_SOCKET
-I/usr/local/include/db3 -DLANGUAGE_C -I.. -DPERL_NO_INLINE_FUNCTIONS
temp.c
cc​: Error​: ../proto.h, line 64​: The function "S__is_utf8_char_slow"
has internal linkage, occurs in a context that requires its
definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE STRLEN S__is_utf8_char_slow(const U8 *s,
const U8 *e)
--------------------------------^
cc​: Error​: ../proto.h, line 161​: The function
"S_append_utf8_from_native_byte" has internal linkage, occurs in a
context that requires its definition, and has no definition.
(missingfunc)
PERL_STATIC_INLINE void S_append_utf8_from_native_byte(const U8 byte,
U8** dest)
------------------------^
cc​: Error​: ../proto.h, line 285​: The function "S_av_top_index" has
internal linkage, occurs in a context that requires its definition,
and has no definition. (missingfunc)
PERL_STATIC_INLINE SSize_t S_av_top_index(pTHX_ AV *av)
--------------------------------^
cc​: Error​: ../proto.h, line 1887​: The function "S_is_safe_syscall" has
internal linkage, occurs in a context that requires its definition,
and has no definition. (missingfunc)
PERL_STATIC_INLINE bool S_is_safe_syscall(pTHX_ const char *pv, STRLEN
len, const char *what, const char *op_name)
------------------------^
cc​: Error​: ../proto.h, line 4473​: The function
"S_sv_only_taint_gmagic" has internal linkage, occurs in a context
that requires its definition, and has no definition. (missingfunc)
PERL_STATIC_INLINE bool S_sv_only_taint_gmagic(SV *sv)
------------------------^
not ok 1
# Failed test 1 - at porting/extrefs.t line 36

I'm responsible for some of those functions. But I don't know why this particular environment would cause them to not be defined. Could you expound on how I/we might solve the problem.

Also, I presume you think this should be a 5.22 blocker. Yes/No?
--
Karl Williamson

The RT System itself - Status changed from 'new' to 'open'

From @jhi

I'm responsible for some of those functions. But I don't know why
this particular environment would cause them to not be defined. Could
you expound on how I/we might solve the problem.

I am guessing, but not have verified (since I noticed this in passing, while cursing at another problem),
that for some reason the compiler is not seeing the bodies (the definitions) of these inline declarations.
Why here in particular, I don't know.

Also, I presume you think this should be a 5.22 blocker. Yes/No?

In theory yes, in practice no. Tru64 is EOLed and actively unsupported by HP.
One failing test in a rare and rejected system should not block 5.22.
(If I find a trivial and correct in other systems fix, I wouldn't mind suggesting it for inclusion, though.)

From @jhi

One failing test in a rare and rejected system should not block 5.22.
(If I find a trivial and correct in other systems fix, I wouldn't mind
suggesting it for inclusion, though.)

I think the Tru64 cc -c99 is playing by the strict C99 rules, which indicate that if there's
"static inline foo" in a header, the definition (the body) MUST also be there somewhere.
(See e.g. http​://www.greenend.org.uk/rjk/tech/inline.html)

Looks the definitions of those functions are in inline.h, which seemingly doesn't get
included with the build done by the extrefs.t.

If I add

#include "inline.h"

after the #include "XSUB.h" in the test code in the extrefs.t the build succeeds
but then link phase fails​:

../perl -I../lib porting/extrefs.t -v
1..1
cccmd = cc -o temp -c99 -no_ansi_alias -D_INTRINSICS -fprm d -ieee -trapuv -readonly_strings -D_SOCKADDR_LEN -D_POSIX_PII_SOCKET -I/usr/local/include/db3 -DLANGUAGE_C -I.. -DPERL_NO_INLINE_FUNCTIONS temp.c
ld​:
Unresolved​:
PL_memory_wrap
not ok 1
# Failed test 1 - at porting/extrefs.t line 36

From @jhi

Random related observation​: it is somehow jarring that we have S_ functions being used across multiple files. Then they are no more static (as in file scope)... maybe there should be a new prefix for the header-defined static inline functions. SI_ ?

But even then, why the heck are we making public APIs out of them?

From @craigberry

On Tue, Mar 31, 2015 at 10​:46 AM, Jarkko Hietaniemi via RT
<perlbug-followup@​perl.org> wrote​:

Random related observation​: it is somehow jarring that we have S_ functions being used across multiple files. Then they are no more static (as in file scope)... maybe there should be a new prefix for the header-defined static inline functions. SI_ ?

But even then, why the heck are we making public APIs out of them?

I think the general idea is that they are a saner way to do what we've
traditionally done with macros. Just like macros, they give you a
separate copy of the code in every file that includes them, but unlike
macros you can type check the arguments, look at what's going on in
the debugger more easily, and there are probably other considerations
I'm not thinking of right now.

It is a little weird having S_ functions in the public API but I
suppose it's pedantically correct because if you use one in your XS
code, you'll be running a static copy of the function that is local to
your .xs file. If you think of them as macros with extra features,
it's really not crazier than what we've always done with macros (and
maybe even a little bit less crazy).

From @jhi

Solution, of sorts, in commit a4570f5

@jhi - Status changed from 'open' to 'resolved'