Issue 36034: Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c (original) (raw)

Created on 2019-02-19 11:56 by Michael.Felt, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (5)
msg335936 - (view) Author: Michael Felt (Michael.Felt) * Date: 2019-02-19 11:56
On a system using an older version of gcc (v5.7.4) I get an error: (also AIX 6.1) gcc -pthread -Wno-unused-result -Wsign-compare -g -O0 -Wall -O -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal -I. -I./Include -DPy_BUILD_CORE_BUILTIN -DPy_BUILD_CORE -I./Include/internal -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'os_preadv_impl': ./Modules/posixmodule.c:8765:9: error: implicit declaration of function 'preadv' [-Werror=implicit-function-declaration] ./Modules/posixmodule.c: In function 'os_pwritev_impl': ./Modules/posixmodule.c:9336:9: error: implicit declaration of function 'pwritev' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors On another system - same code base (commit e7a4bb554edb72fc6619d23241d59162d06f249a) no "error" status. (AIX 7.2) Not knowing gcc I have no idea which is correct - maybe they both are because the second system (where I am a guest) has an explicit declaration of these routines. Is there a flag I can add to gcc to get the "in-line" pre-processing output so I can look for differences with regard to these two functions? Thanks for hint.
msg335938 - (view) Author: Michael Felt (Michael.Felt) * Date: 2019-02-19 12:10
correction - gcc version is v4.7.4
msg336017 - (view) Author: Alexey Izbyshev (izbyshev) * (Python triager) Date: 2019-02-19 20:29
I don't know what you mean by "in-line" pre-processing output, but you can use -E option to get the normal preprocessor output. Line directives will tell you where those functions come from on a system where there is no compilation error. Of course, if those functions are defined in some other headers on AIX 6.1, it won't help you, so you might as well just grep /usr/include :)
msg336205 - (view) Author: Michael Felt (Michael.Felt) * Date: 2019-02-21 11:19
xlc has an option -qsource that creates output like this - first showing the code with macro, then showing the expansion >>>>> SOURCE SECTION <<<<< ...        16 |         dev = st.st_dev;        17 minor = minor(dev);        17 +         minor = (int)((dev)&0xFFFF);        18 major = major(dev);        18 +         major = (int)((unsigned)(dev)>>16); I'll check and see if -E processes the output in the same way. Thx. On 2/19/2019 9:29 PM, Alexey Izbyshev wrote: > Alexey Izbyshev <izbyshev@ispras.ru> added the comment: > > I don't know what you mean by "in-line" pre-processing output, but you can use -E option to get the normal preprocessor output. Line directives will tell you where those functions come from on a system where there is no compilation error. > > Of course, if those functions are defined in some other headers on AIX 6.1, it won't help you, so you might as well just grep /usr/include :) > > ---------- > nosy: +izbyshev > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue36034> > _______________________________________ >
msg361298 - (view) Author: Michael Felt (Michael.Felt) * Date: 2020-02-03 14:23
closing. Will open a new issue with a correct description of the issue at hand. The problem is related to 64-bit mode (which was not mentioned before) and minor() major() macro definitions.
History
Date User Action Args
2022-04-11 14:59:11 admin set github: 80215
2020-10-16 08:45:33 izbyshev set resolution: not a bug
2020-02-03 14:23:23 Michael.Felt set status: open -> closedmessages: + stage: resolved
2019-02-21 11:19:04 Michael.Felt set messages: +
2019-02-19 20:29:45 izbyshev set nosy: + izbyshevmessages: +
2019-02-19 12:10:36 Michael.Felt set messages: +
2019-02-19 11:56:01 Michael.Felt create