ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Why does bloom `export LDFLAGS=`?

asked 2020-07-03 17:42:10 -0500

rubicks gravatar image

updated 2020-07-07 09:56:16 -0500

As of this writing, the bloom repository has at least one debian/rules template featuring the following comment:

# TODO: remove the LDFLAGS override.  It's here to avoid esoteric problems
# of this sort:
#  https://code.ros.org/trac/ros/ticket/2977
#  https://code.ros.org/trac/ros/ticket/3842
export LDFLAGS=

-- https://github.com/ros-infrastructure...

Those commented links are dead, and the internet archive wayback machine doesn't have them. The distant ancestor of that file already had those comments when it was added in 2012:

https://github.com/ros-infrastructure...

Does anyone remember what ROS trac tickets 2977 and 3842 were about? What were those "esoteric problems" mentioned by the author?

_Update_:

My ROS friends have pointed me toward catkin issue #72 and a commit referencing the same:

https://github.com/ros/catkin/commit/...

It's clear this LDFLAGS override has something to do with preventing the linker from seeing the -Bsymbolic-functions flag. More detail forthcoming as I dig into it.

_Update The Second_:

My further searching has led to several tickets reporting runtime segfaults caused by the use of -Bsymbolic-functions during the link phase:

It is the dpkg-buildflags command (of Ubuntu's dpkg-dev package) that adds -Bsymbolic-functions to the LDFLAGS during a normal dpkg-buildpackage:

root@c7dc18648a0e:/# cat /etc/issue.net && dpkg-buildflags --get LDFLAGS
Ubuntu 20.04 LTS
-Wl,-Bsymbolic-functions -Wl,-z,relro

Note that the Debian dpkg-dev does _not_ do this:

root@b134afb3a682:/# cat /etc/issue.net && dpkg-buildflags --get LDFLAGS
Debian GNU/Linux 10
-Wl,-z,relro

The "proper" way to remove options from the set of linker flags is explained in man 1 dpkg-buildflags "Environment" section:

DEB_flag_STRIP DEB_flag_MAINT_STRIP This variable can be used to provide a space separated list of options that will be stripped from the set of flags returned for the given flag.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
4

answered 2020-07-06 19:35:47 -0500

gerkey gravatar image

After a trip into the basement where they keep the Ark of the Covenant, I found an email that I sent to Jeremy Leibs and Ken Conley looking for advice on this topic in February 2012:

John and I spent quite some time yesterday tracking down a segfault that was only happening when using a .deb built by our new catkin-based debbuilder, and could not be reproduced by compiling the crashing library from source. Turns out that we could reproduce it by building the library with -Wl,-Bsymbolic-functions on the link line. And that's what pbuilder is doing in the new debbuilder.

That whole sequence rang a distant bell in my mind, and I then found this gem of a ticket: https://code.ros.org/trac/ros/ticket/... So we've simply re-encountered the problem.

The space of solutions is the same, with the "right" answer likely being to force everybody to use -Wl,-Bsymbolic-functions in their own development, and fixing underlying bugs. But at this point, I don't have time before the Fuerte release to work through the regressions that would surely result.

So: do you recall how you "cleared out LDFLAGS in the current deb-building system"? I'd like to do the same in the new system.

We'll do our best to address this properly in the next release cycle, starting early.

What followed in the email thread amounted to, "yeah, it's best to add LDFLAGS= somewhere in the pipeline". The description of the resulting catkin issue is simply a copy and paste of Ken's response along those lines.

I do not recall what the actual problem was. After reading through this ancient history, my guess is:

  • Somewhere in the normal deb-building pipeline (at least when using pbuilder), somebody adds -Wl,-Bsymbolic-functions to LDFLAGS.
  • That addition is probably done for some good reason and it's probably not supposed to cause harm.
  • Unfortunately it can sometimes cause harm, probably by exposing some underlying bug or flawed assumption in the code that is being built into a deb.
  • We papered over the bug/flaw by wiping out LDFLAGS.
  • We intended to address the underlying bug/flaw but probably never made it happen.

Unfortunately, from the description that I gave to Ken and Jeremy, it seems like whatever problem arises when using -Wl,-Bsymbolic-functions may present itself as a tricky segfault. So my guess is that it's not safe to remove the LDFLAGS override. Or at least it would be hard to prove that it's safe.

edit flag offensive delete link more
0

answered 2020-07-23 20:23:22 -0500

tfoote gravatar image

Here's some background I manually dug out of the archives.

Ticket 2977

Reporter

kwc

Description

jfaust, wim, and myself have been perplexed by compiler flag behavior leading to heisenbugs: a package that fails to build successfully builds with a "make clean; make", probably due to different compiler flags. Also, the new compiler flags do not appear to be correct.

This is seen with pr2_ethercat_drivers, which fails to build in the new debbuild system:

http://build.willowgarage.com/view/debbuild/job/debbuild-build-debs-unstable-lucid-amd64/19/console

The errors are of this form:
{{{
 Linking CXX executable ../motorconf
  Linking CXX shared library ../lib/libethercat_hardware.so
  CMakeFiles/motorconf.dir/src/wg0x.o: In function `realtime_tools::RealtimePublisher<pr2_msgs::PressureState_<std::allocator<void> > >::unlockAndPublish()':
  /opt/ros/unstable/stacks/pr2_mechanism/realtime_tools/include/realtime_tools/realtime_publisher.h:134: undefined reference to `boost::condition_variable::notify_one()'
  CMakeFiles/motorconf.dir/src/wg0x.o: In function `realtime_tools::RealtimePublisher<pr2_msgs::AccelerometerState_<std::allocator<void> > >::unlockAndPublish()':
}}}

and reproducible if you run:
{{{
sudo apt-get install pbuilder -y
rosrun rosdeb build_debs.py unstable pr2_ethercat_drivers lucid amd64 --interactive --force --noupload --noramdisk
}}}

When you initially load the system, you'll see the linker error. If you proceed to run:

{{{
export ROS_DESTDIR=/tmp/buildd/ros-unstable-pr2-ethercat-drivers-1.2.0/debian/ros-unstable-pr2-ethercat-drivers
. /tmp/buildd/ros-unstable-pr2-ethercat-drivers-1.2.0/setup_deb.sh
roscd ethercat_hardware
make clean; make
}}}

The error goes away. We've run this with "VERBOSE=1 make" to capture the build flags and seen that they are different. You'll also see that 'errorGood.txt' has '-O2', even though ethercat_hardware is set to "Debug" (separately ticketed).

I've attached 'errorBad.txt' and 'errorGood.txt'

Comments

y c 1 The difference between the two set of flags is that the bad build add
o
m Digging...

y c 2 Ok, I can reproduce the bad link line, though not the linker failure
o
{{{
m roscd ethercat_hardware
m make clean
e
LDFLAGS="-O2 -g -Wl,-Bsymbolic-functions" make VERBOSE=1
n
}}}
t
The LDFLAGS args get inserted in the same place near the beginning of
My hypothesis: inside the environment created by pbuilder, something
I would guess that you'll find the same flags in every link step, in
Perhaps those flags are part of Ubuntu's standard package-building sy
2
9
7
7 1 k c 3 I'll pass this off to Jeremy. My 1/4 of build engineer brain does not know about pbuilder

c 4 Googling around supports my hypothesis:
o
m
* "debuild/dpkg-buildpackage have system defaults for CFLAGS, CXXFLA
m
* "On Ubuntu (as of hardy), dpkg-buildpackage sets LDFLAGS to contai
e
n
t
2 1 g c 5 I'm inclined to say that, unless Debian/Ubuntu has been careless or controversial in the build

7 1 le c 6 So what seems to be this exact same bug led to another problem, which
2 ib o
8 s m We either need to disable these flags in the build system, or add the

c 7 Presumably it's `-Wl,-Bsymbolic-functions` that's causing the trouble
o
m That won't make everybody use it ...
(more)
edit flag offensive delete link more

Question Tools

3 followers

Stats

Asked: 2020-07-03 17:42:10 -0500

Seen: 403 times

Last updated: Jul 23 '20