libpano13: INLINE problem

[johnfi...@gmail.com]

Due to the way inline works in c in gcc, I got errors building a debug build of libpano13 in fedora.

I know several different ways to fix the problem.  But I don't know enough about all the ways libpano13 might be built and/or used to have a safe opinion on which way is best.

Despite reading many results of google searches and official gcc descriptions, I still can't understand the general rules for inline in gcc c (which are very different from c++ rules).  But I do understand this example of the use of inline and why it is wrong.

Some questions:

Has anyone else built libpano13 debug in Linux?  Did you need to work around the problem described below?  If so, how?  If not, do you have an idea of why it worked for you and not for me?

Are the functions float2rgbe and rgbe2float supposed to be exposed to clients of libpano13?  Or are they purely internal?  Currently in Linux (at least the Fedora package and my own builds in Fedora) they are not exposed.  But I don't know if they were meant to be.  In fact they are not even exposed to the rest of libpano13 outside of rgbe.c, despite being declared in rgbe.h as if they were meant to be exposed.

As currently declared/defined they are never instantiated as individual functions.  They might be inlined wherever used within rgbe.c or they might be undefined.  That is entirely a free choice of the optimizer, except at lowest optimization level, where they are necessarily undefined.

My current work around:

I added  __attribute__((always_inline)) to the end of line 41 of pt_stdint.h (which is already inside a conditional excluding MSC).

That further entrenches the current behavior that c functions using the INLINE macro are not ever usable outside translation units that define them, while it fixes the undefines for unoptimized builds.  It forces functions defined that way to be inlined even in the debug build.

[johnfi...@gmail.com]

On Friday, March 11, 2022 at 3:46:32 PM UTC-5 johnfi...@gmail.com wrote:

Are the functions float2rgbe and rgbe2float supposed to be exposed to clients of libpano13?  Or are they purely internal?  Currently in Linux (at least the Fedora package and my own builds in Fedora) they are not exposed.  But I don't know if they were meant to be.  In fact they are not even exposed to the rest of libpano13 outside of rgbe.c, despite being declared in rgbe.h as if they were meant to be exposed.

I see that Thomas fixed this problem today in a way that clarifies the intent that these two functions are not exposed outside rgbe.c

[Andreas Metzler]

On 2022-03-11 "johnfi...@gmail.com" <johnfi...@gmail.com> wrote:
> Due to the way inline works in c in gcc, I got errors building a debug
> build of libpano13 in fedora.

[...]

> Has anyone else built libpano13 debug in Linux? Did you need to work
> around the problem described below? If so, how? If not, do you have an
> idea of why it worked for you and not for me?

[...]

Hello John,

could you explain how your problems manifested? To build on Debian with
debug symbols I have not done anything special, letting the usuals
distro magic make sure that the necessary build flags (-g) are used.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[John Fine]

On Sun, Apr 3, 2022 at 9:04 AM Andreas Metzler <amet...@bebt.de> wrote:

could you explain how your problems manifested? To build on Debian with
debug symbols I have not done anything special, letting the usuals
distro magic make sure that the necessary build flags (-g) are used.

I meant "debug" as the type of build, not the "release with debug symbols" type of build.

Having debug symbols (-g) is unrelated to the problem.  The debug type of build turns off inlining.  The original code was not correct unless the optimizer inlined it.

Before Thomas fixed it, the two symbols would be undefined at link time in a build in which the optimizer did not inline every use of those functions.