> Hi,
>
> I disabled lto in a build according to the instructions from [1]:
>
> export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
>
> But I saw that it was still present in some steps of the build.
> Notably when krb5/gssapi was used:
> ...
> -- Found GSSAPI: -L/usr/lib/x86_64-linux-gnu/mit-krb5
> -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto
> -Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
> ...
> /usr/bin/cc -fPIC -g -O2
> -ffile-prefix-map=/home/ubuntu/git/packages/mariadb/mariadb-10.6=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC
> -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wlogical-op
> -Wno-uninitialized -Wall -Wextra -Wformat-security -Wno-init-self
> -Wwrite-strings -Wshift-count-overflow -Wdeclaration-after-statement
> -Wno-undef -Wno-unknown-pragmas -O2 -g -static-libgcc
> -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized
> -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
> -Wdeclaration-after-statement -Wextra -Wformat-security
> -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
> -Wno-unused-parameter -Wvla -Wwrite-strings -DDBUG_OFF
> -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro,-z,now -shared -o
> auth_gssapi_client.so
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/auth_gssapi_client.c.o
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_client.c.o
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_errmsg.c.o
> -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
> -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
> -lkrb5 -lk5crypto -lcom_err
>
> Indeed in this case it comes from kerberos/gssapi:
>
> $ krb5-config --libs gssapi
> -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
> -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
> -lkrb5 -lk5crypto -lcom_err
>
> That sounds bad. It means only portions of the build will have lto
> disabled, while others will flip it back on. How to sort this out?
> Looks like the krb5 package needs some fixing, but I'm unsure how.
Just reiterating what I told you during standup, this leakage is wrong
and should be fixed in krb5's pkg-config definitions.
Some interesting things to consider here:
- Debian/Ubuntu differ from Fedora in the sense that we specify the LTO
flags during link time as well (LDFLAGS), while Fedora only specifies
them during compile time. GCC can auto-detect LTO bytecode during
link time and will do the right thing even if no LTO flags are passed
(as long as we use GCC to perform the link, which we do). So in
theory we could remove the "-flto -ffat-lto-objects" from our LDFLAGS
and still have LTO-enabled binaries.
- As a direct consequence of the above, the exact same command yields a
different result in Fedora, even though they also have LTO enabled.
- GCC will also be smart enough when mix & matching object files and
libraries that were compiled with and without LTO, so no worries
here.
Either way, I believe this issue should be addressed in krb5 as I said
above. I haven't been able to find any bug about this in upstream's bug
tracker.
Thanks,
--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
