Quantcast

release vs relwithdebinfo

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

release vs relwithdebinfo

rusu
Administrator
Hi all,

This question is mainly for our ROS PCL users, as that's the only forum where we provide binaries for PCL (via DEB
packages)...

We did some tests yesterday and we discovered that in its default "RelWithDebInfo" configuration, the perception_pcl
stack libraries occupy around 300MB, due to the explicit template instantiations that we do there. (More on how to
improve this for 2.0 later.) However, when changed to "Release", the entire think dropped to 30MB or so.

Right now we have no way to change between the two modes while we build the debian packages (we could create a ticket
for that if we feel it's necessary), so we have to select one or the other.

Do folks here have any preferences? If you're doing development, and you're missing out on debug information, it might
be hard to trace bugs. And PCL can be buggy -- "stable" means the API is locked, not that we solved all our bugs :)

However, is the archive size is important, and you would like to apt-get install less stuff, going to Release will
shrink down the files by an order of magnitude.

Suggestions? Ideas?


Thanks,
Radu.
--
http://pointclouds.org
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release vs relwithdebinfo

Kevin Watts
I think the debug symbols are worth the extra 270MB of space. 


On Tue, Feb 22, 2011 at 10:51 AM, Radu Bogdan Rusu <[hidden email]> wrote:
Hi all,

This question is mainly for our ROS PCL users, as that's the only forum where we provide binaries for PCL (via DEB
packages)...

We did some tests yesterday and we discovered that in its default "RelWithDebInfo" configuration, the perception_pcl
stack libraries occupy around 300MB, due to the explicit template instantiations that we do there. (More on how to
improve this for 2.0 later.) However, when changed to "Release", the entire think dropped to 30MB or so.

Right now we have no way to change between the two modes while we build the debian packages (we could create a ticket
for that if we feel it's necessary), so we have to select one or the other.

Do folks here have any preferences? If you're doing development, and you're missing out on debug information, it might
be hard to trace bugs. And PCL can be buggy -- "stable" means the API is locked, not that we solved all our bugs :)

However, is the archive size is important, and you would like to apt-get install less stuff, going to Release will
shrink down the files by an order of magnitude.

Suggestions? Ideas?


Thanks,
Radu.
--
http://pointclouds.org
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

Nizar Khalifa Sallem
In reply to this post by rusu
At Tue, 22 Feb 2011 10:51:57 -0800,
Radu Bogdan Rusu wrote:

>
> Hi all,
>
> This question is mainly for our ROS PCL users, as that's the only forum where we provide binaries for PCL (via DEB
> packages)...
>
> We did some tests yesterday and we discovered that in its default "RelWithDebInfo" configuration, the perception_pcl
> stack libraries occupy around 300MB, due to the explicit template instantiations that we do there. (More on how to
> improve this for 2.0 later.) However, when changed to "Release", the entire think dropped to 30MB or so.
>
> Right now we have no way to change between the two modes while we build the debian packages (we could create a ticket
> for that if we feel it's necessary), so we have to select one or the other.
Hi Radu,

You don't need nothing for this as it is handled by cmake you can even
pass it in force throug -DCMAKE_BUILD_TYPE=Release or
-DCMAKE_BUILD_TYPE=DebugWithInfo or -DCMAKE_BUILD_TYPE=Debug but for
other kind of builds you will probably need more work but for those
ones they are recognized by cmake.

>
> Do folks here have any preferences? If you're doing development, and you're missing out on debug information, it might
> be hard to trace bugs. And PCL can be buggy -- "stable" means the API is locked, not that we solved all our bugs :)
>
> However, is the archive size is important, and you would like to apt-get install less stuff, going to Release will
> shrink down the files by an order of magnitude.
>
> Suggestions? Ideas?
>
>
> Thanks,
> Radu.
> --
> http://pointclouds.org
> _______________________________________________
> [hidden email] / http://pointclouds.org
> https://code.ros.org/mailman/listinfo/pcl-users
--
Nizar
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

Eric Perko
In reply to this post by rusu
On Tue, Feb 22, 2011 at 1:51 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Hi all,

This question is mainly for our ROS PCL users, as that's the only forum where we provide binaries for PCL (via DEB
packages)...

We did some tests yesterday and we discovered that in its default "RelWithDebInfo" configuration, the perception_pcl
stack libraries occupy around 300MB, due to the explicit template instantiations that we do there. (More on how to
improve this for 2.0 later.) However, when changed to "Release", the entire think dropped to 30MB or so.

Right now we have no way to change between the two modes while we build the debian packages (we could create a ticket
for that if we feel it's necessary), so we have to select one or the other.

Do folks here have any preferences? If you're doing development, and you're missing out on debug information, it might
be hard to trace bugs. And PCL can be buggy -- "stable" means the API is locked, not that we solved all our bugs :)

However, is the archive size is important, and you would like to apt-get install less stuff, going to Release will
shrink down the files by an order of magnitude. 

Suggestions? Ideas?

Can we have it both ways? :)

For example, there are numerous libraries in the Ubuntu repositories that provide both a -dbg and a regular version. One example: the GNU C library has both the "libc6" package, as well as the "libc6-dbg" package that provides debugging symbols (or a version that doesn't have debugging symbols stripped out). I'm a bit fuzzy on exactly what they are doing, but my point is that they have two separate packages, one with debugging symbols and one without and I get to choose which to install. Could PCL do something similar?

I can see being able to choose which side of the tradeoff I want being useful. For example, on my development workstations I would prefer the debugging symbols and have disk space aplenty to waste on them when I'm not using them. On the robot however, disk space is very limited and we generally don't do debugging directly on the robot, so saving 270MB on debugging symbols that won't get used would be a definite win.

I'm not sure how this would affect the debs that depend on PCL though. Can we mix and match code compiled with and without debugging symbols without any downsides? Would there need to be two sets of debs for every single package that depended on PCL (transitively), one set that boiled down to depending on the Release build and one set that depended on the -dbg version? Could the -dbg version just say it "provides" the standard version and then all packages can safely depend solely on ros-*-perception-pcl without caring whether I've installed the version with or without debugging symbols?

- Eric
 


Thanks,
Radu.
--
http://pointclouds.org
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

Nizar Khalifa Sallem
At Tue, 22 Feb 2011 14:59:38 -0500,
Eric Perko wrote:

>
> On Tue, Feb 22, 2011 at 1:51 PM, Radu Bogdan Rusu <[hidden email]> wrote:
>
>     Hi all,
>    
>     This question is mainly for our ROS PCL users, as that's the only forum where we provide binaries for PCL (via DEB
>     packages)...
>    
>     We did some tests yesterday and we discovered that in its default "RelWithDebInfo" configuration, the perception_pcl
>     stack libraries occupy around 300MB, due to the explicit template instantiations that we do there. (More on how to
>     improve this for 2.0 later.) However, when changed to "Release", the entire think dropped to 30MB or so.
>
>     Right now we have no way to change between the two modes while we build the debian packages (we could create a ticket
>     for that if we feel it's necessary), so we have to select one or the other.
>    
>     Do folks here have any preferences? If you're doing development, and you're missing out on debug information, it might
>     be hard to trace bugs. And PCL can be buggy -- "stable" means the API is locked, not that we solved all our bugs :)
>    
>     However, is the archive size is important, and you would like to apt-get install less stuff, going to Release will
>     shrink down the files by an order of magnitude. 
>
>     Suggestions? Ideas?
>
> Can we have it both ways? :)
>
> For example, there are numerous libraries in the Ubuntu repositories that provide both a -dbg and a regular version. One example: the GNU C library has both the "libc6" package, as
> well as the "libc6-dbg" package that provides debugging symbols (or a version that doesn't have debugging symbols stripped out). I'm a bit fuzzy on exactly what they are doing, but
> my point is that they have two separate packages, one with debugging symbols and one without and I get to choose which to install. Could PCL do something similar?
>
> I can see being able to choose which side of the tradeoff I want being useful. For example, on my development workstations I would prefer the debugging symbols and have disk space
> aplenty to waste on them when I'm not using them. On the robot however, disk space is very limited and we generally don't do debugging directly on the robot, so saving 270MB on
> debugging symbols that won't get used would be a definite win.
>
> I'm not sure how this would affect the debs that depend on PCL though. Can we mix and match code compiled with and without debugging symbols without any downsides? Would there need
> to be two sets of debs for every single package that depended on PCL (transitively), one set that boiled down to depending on the Release build and one set that depended on the
> -dbg version? Could the -dbg version just say it "provides" the standard version and then all packages can safely depend solely on ros-*-perception-pcl without caring whether I've
> installed the version with or without debugging symbols?
>
> - Eric
>  
>
>     Thanks,
>     Radu.
>     --
>     http://pointclouds.org
>     _______________________________________________
>     [hidden email] / http://pointclouds.org
>     https://code.ros.org/mailman/listinfo/pcl-users
>
>
I completely agree with Eric many libraries have a release and a debug
version and personaly in my projects I do have the release for
deployment and debug for wip but I will back to the discussion I had
once with Radu about writing real CMakeLists.txt for PCL, which can
solve this problem along with the install issue (another point for the
pcl-1.0 :) ).

--
Nizar


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

rusu
Administrator
Interesting suggestion.

I am not sure if creating extra -dbg puts a large burden on our debian package generation system, but if it doesn't,
that sounds like a great idea!

Thanks for the feedback!

PS. We have the same problem with many libraries not just PCL. I was talking about PCL in my e-mail because that's the
one we tested.

Cheers,
Radu.
--
http://pointclouds.org

On 02/22/2011 12:24 PM, Nizar Khalifa Sallem wrote:
>> For example, there are numerous libraries in the Ubuntu repositories that provide both a -dbg and a regular version. One example: the GNU C library has both the "libc6" package, as
>> well as the "libc6-dbg" package that provides debugging symbols (or a version that doesn't have debugging symbols stripped out). I'm a bit fuzzy on exactly what they are doing, but
>> my point is that they have two separate packages, one with debugging symbols and one without and I get to choose which to install. Could PCL do something similar?
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

Peter Soetens-2
On Wednesday 23 February 2011 01:46:51 Radu Bogdan Rusu wrote:

> Interesting suggestion.
>
> I am not sure if creating extra -dbg puts a large burden on our debian
> package generation system, but if it doesn't, that sounds like a great
> idea!
>
> Thanks for the feedback!
>
> PS. We have the same problem with many libraries not just PCL. I was
> talking about PCL in my e-mail because that's the one we tested.

In the Orocos debian packages, we build with RelWithDebInfo and strip out the
debug symbols into a separate package during the packaging step. This is done
by adding the
        dh_strip --dbg-package=orocos-rtt-dbg$(major)

step in the 'binary-arch:' target in your debian/rules file. The -dbg package
is automatically generated, in our case, that's "orocos-rtt-
dbg2.3_2.3.0-1.deb" for the 2.3.0 release. Our control file then contains this
text for defining the -dbg package:

Package: orocos-rtt-dbg@LIBVER@
Section: libdevel
Priority: extra
Architecture: any
Depends: liborocos-rtt-common@LIBVER@-dev (= ${binary:Version})
Conflicts: orocos-rtt-dbg
Replaces:  orocos-rtt-dbg
Provides:  orocos-rtt-dbg
Description: Orocos Real-Time Toolkit (debug symbols)
 .
 This package contains the debugging symbols.

There is a confusion in this thread that -dbg packages must depend on other -
dbg packages. That is not the case. All 'lib' packages depend only on the
'lib' packages, and not  on the -dbg packages. So you could pick to only
install the -dbg symbols only for one library 'in the middle'.

It's certainly not a stress to generate these -dbg packages, it only takes a
few seconds, and it's fully automated by the Debian build system.

>
> Cheers,
> Radu.
> --
> http://pointclouds.org
>
> On 02/22/2011 12:24 PM, Nizar Khalifa Sallem wrote:
> >> For example, there are numerous libraries in the Ubuntu repositories
> >> that provide both a -dbg and a regular version. One example: the GNU C
> >> library has both the "libc6" package, as well as the "libc6-dbg"
> >> package that provides debugging symbols (or a version that doesn't have
> >> debugging symbols stripped out). I'm a bit fuzzy on exactly what they
> >> are doing, but my point is that they have two separate packages, one
> >> with debugging symbols and one without and I get to choose which to
> >> install. Could PCL do something similar?
>

Peter
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PCL-users] release vs relwithdebinfo

rusu
Administrator
Peter,

That's a great suggestion! Thanks!

We have a ticket that captures this now: https://code.ros.org/trac/ros/ticket/3365

Cheers,
Radu.
--
http://pointclouds.org

On 02/23/2011 01:56 AM, Peter Soetens wrote:

> On Wednesday 23 February 2011 01:46:51 Radu Bogdan Rusu wrote:
>> Interesting suggestion.
>>
>> I am not sure if creating extra -dbg puts a large burden on our debian
>> package generation system, but if it doesn't, that sounds like a great
>> idea!
>>
>> Thanks for the feedback!
>>
>> PS. We have the same problem with many libraries not just PCL. I was
>> talking about PCL in my e-mail because that's the one we tested.
>
> In the Orocos debian packages, we build with RelWithDebInfo and strip out the
> debug symbols into a separate package during the packaging step. This is done
> by adding the
> dh_strip --dbg-package=orocos-rtt-dbg$(major)
>
> step in the 'binary-arch:' target in your debian/rules file. The -dbg package
> is automatically generated, in our case, that's "orocos-rtt-
> dbg2.3_2.3.0-1.deb" for the 2.3.0 release. Our control file then contains this
> text for defining the -dbg package:
>
> Package: orocos-rtt-dbg@LIBVER@
> Section: libdevel
> Priority: extra
> Architecture: any
> Depends: liborocos-rtt-common@LIBVER@-dev (= ${binary:Version})
> Conflicts: orocos-rtt-dbg
> Replaces:  orocos-rtt-dbg
> Provides:  orocos-rtt-dbg
> Description: Orocos Real-Time Toolkit (debug symbols)
>   .
>   This package contains the debugging symbols.
>
> There is a confusion in this thread that -dbg packages must depend on other -
> dbg packages. That is not the case. All 'lib' packages depend only on the
> 'lib' packages, and not  on the -dbg packages. So you could pick to only
> install the -dbg symbols only for one library 'in the middle'.
>
> It's certainly not a stress to generate these -dbg packages, it only takes a
> few seconds, and it's fully automated by the Debian build system.
>
>>
>> Cheers,
>> Radu.
>> --
>> http://pointclouds.org
>>
>> On 02/22/2011 12:24 PM, Nizar Khalifa Sallem wrote:
>>>> For example, there are numerous libraries in the Ubuntu repositories
>>>> that provide both a -dbg and a regular version. One example: the GNU C
>>>> library has both the "libc6" package, as well as the "libc6-dbg"
>>>> package that provides debugging symbols (or a version that doesn't have
>>>> debugging symbols stripped out). I'm a bit fuzzy on exactly what they
>>>> are doing, but my point is that they have two separate packages, one
>>>> with debugging symbols and one without and I get to choose which to
>>>> install. Could PCL do something similar?
>>
>
> Peter
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Loading...