Bug 25994 - inproper order of PATH set cause wrong unexpected gcc used
Summary: inproper order of PATH set cause wrong unexpected gcc used
Status: RESOLVED WORKSFORME
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-15 06:50 UTC by xuchunmei
Modified: 2020-07-03 03:01 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
add default "/usr/bin:/bin" after $PATH (854 bytes, application/mbox)
2020-05-15 06:50 UTC, xuchunmei
Details

Note You need to log in before you can comment on or make changes to this bug.
Description xuchunmei 2020-05-15 06:50:13 UTC
Created attachment 12541 [details]
add default "/usr/bin:/bin" after $PATH

My use case is like this, I install gcc-4.8.5 and devtoolset-9-gcc,
while I set the PATH by "source /opt/rh/devtoolset-9/enable" to use
gcc-9, but when I use "stap test.stap", I always get compile errors
for "gcc: error: unrecognized command line option
‘-fpatchable-function-entry=2’", the option
‘-fpatchable-function-entry=2’ is not supported by gcc-4.8.5 but
supported by gcc-9.
The stap process building always use gcc-4.8.5 from /usr/bin not from
the first path of PATH, such as /opt/rh/devtoolset-9/root/usr/bin/gcc.

As I think the default /usr/bin:/bin should be added after $PATH.

I add an attachment to fix it, please have a review.
Comment 1 Frank Ch. Eigler 2020-05-15 12:40:49 UTC
The problem is that for systemtap to build kernel modules compatible with the system kernel, it must use the same compiler.  Jumping between major versions can create incompatible modules, whether enforced by symbol versioning type metadata, or undetected inconsistencies in kernel struct declarations.

Any idea where those -fpatchable-function-entry=2 cflags are coming from?  Maybe we can nuke those from within stap more properly.
Comment 2 xuchunmei 2020-05-16 02:25:14 UTC
(In reply to Frank Ch. Eigler from comment #1)
> The problem is that for systemtap to build kernel modules compatible with
> the system kernel, it must use the same compiler.  Jumping between major
> versions can create incompatible modules, whether enforced by symbol
> versioning type metadata, or undetected inconsistencies in kernel struct
> declarations.
> 
> Any idea where those -fpatchable-function-entry=2 cflags are coming from? 
> Maybe we can nuke those from within stap more properly.

yes, My kernel is build with devtoolset-9-gcc, and systemtap is also build with devtoolset-9, when I use systemtap I want to use gcc which is /opt/rh/devtoolset-9/root/usr/bin/gcc not /usr/bin/gcc.

the "-fpatchable-function-entry=2" is from arch/arm64/Makefile:

ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
  KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
  CC_FLAGS_FTRACE := -fpatchable-function-entry=2
endif
Comment 3 Frank Ch. Eigler 2020-05-16 09:51:26 UTC
> yes, My kernel is build with devtoolset-9-gcc

Ahh, interesting.

Try: 
   # scl enable .... bash
   # stap -B CC=/opt/rh/...../bin/gcc  <options>

The -B option passes through kbuild make options.
Comment 4 xuchunmei 2020-05-16 10:44:05 UTC
(In reply to Frank Ch. Eigler from comment #3)
> > yes, My kernel is build with devtoolset-9-gcc
> 
> Ahh, interesting.
> 
> Try: 
>    # scl enable .... bash
>    # stap -B CC=/opt/rh/...../bin/gcc  <options>
> 
> The -B option passes through kbuild make options.

ok,I try it, and it works, thanks.
Comment 5 xuchunmei 2020-07-03 03:01:02 UTC
it is not a problem, can use -B option to set kbuild make options