@vorlon - adding to Fabio's question. I agree with your reasoning that
the workarounds should be reasonably easy for a knowledgeable user. We
should enable end users to apply the same fix since they may be affected
without realizing it. While we shouldn't encourage users to stay on 2.7,
there are apps that either won't transition or still have a large amount
of work to do so. For Jammy, I believe these apps can be effectively
guaranteed security patches until 2032.

I believe the path below avoids the regression concerns. Its a bit ugly,
but it at least won't outlive Jammy. None of this is ideal, but I think
solves both sides of the equation.


* Add a feature flag that applies the proposed fix when present. This should be 
the default to satisfy the initial bug report constraint. Maybe 
UBUNTU_APPLY_DEFAULT_PYTHON_CFLAGS_ON_EXTENSIONS? Extremely verbose, but very 
little chance of someone accidentally disabling it. We should also print when 
its used so users have a launchpad issue to reference if it happens to cause a 
regression for a out of distro package compilation.
* Prevent applying the above feature flag for packages that already exist in 
the archive. This is a static list that is very unlikely to change. This does 
assume that distutils.sysconfig has a mechanism to introspect the package 
currently being built. Public API hints that it MAY be possible, but I haven't 
done thorough inspection across the ecosystem of callers.


Would you support a solution similar to the above?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/2002043

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  In Progress
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Won't Fix
Status in python2.7 source package in Jammy:
  Won't Fix
Status in python2.7 source package in Kinetic:
  Won't Fix
Status in python2.7 source package in Lunar:
  Won't Fix
Status in python2.7 source package in Mantic:
  Won't Fix

Bug description:
  Compiling a Python extension using Python2 (Python 2.7.18) is making
  use of wrong compiler flags, hence dropping required optimizations
  when required. This is happening only when python2 is installed from
  Ubuntu's repositories. By default, Python's distutils module uses
  compiler and linker flags used to compile Python itself to be used to
  compile extensions.

  Steps to reproduce:
  1) On Ubuntu 20.04, install python2 using apt package manager.
  2) After successful installation, verify the CFLAGS variable from sysconfig 
module. On my machine, the output is 

  Python 2.7.18 (default, Jul  1 2022, 12:27:04)
  [GCC 9.4.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import sysconfig
  >>> sysconfig.get_config_var('CFLAGS')
  '-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=. 
-fstack-protector-strong -Wformat -Werror=format-security  '

  3) Build a test extension module using python2 and verify the compilation 
flags. 
  python2 setup.py build_ext --inplace

  Output from below command is not matching with our expected above CFLAGS. 
  aarch64-linux-gnu-gcc -pthread -fno-strict-aliasing -Wdate-time 
-D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c testmodule.c -o 
build/temp.linux-aarch64-2.7/testmodule.o

  
  On further investigation, it looks like Ubuntu's specific patch applied on 
libpython2.7-stdlib package is altering the original upstream implementation of 
distutils/sysconfig.py code.

  Package - https://packages.ubuntu.com/focal/libpython2.7-stdlib
  Patch - 
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz

  Below is the code block which is causing the issue, where the presence of 
configure_cflags is modifying cflags. This code is result of ubuntu's patch and 
doesn't come directly from upstream python implementation.
  File - /usr/lib/python2.7/distutils/sysconfig.py
  Part of code block:
          elif configure_cflags:
              cflags = ' '.join(str(x) for x in (basecflags, configure_cflags, 
extra_cflags) if x)
              ldshared = ldshared + ' ' + configure_cflags

  
  I don't see problem on Python3 though we have extra code added from patch 
there as well. Patch used on python3, is not modifying the cflags completely 
and instead appending new flags to cflags.
  On python3 (tested on Ubuntu 20.04)
  File - /usr/lib/python3.8/distutils/sysconfig.py
  Part of code block which doesn't alter cflags completely
          elif configure_cflags:
              cflags = cflags + ' ' + configure_cflags
              ldshared = ldshared + ' ' + configure_cflags

  
  Request to update the python2 patch to behave similar to what is been done on 
python3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/2002043/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to