Community
Participate
Working Groups
Build Identifier: CDT 7.0 Actually it is not possible to debug a libtool generated executable, because the debug launcher does not allow to specify an executable script to debug. If you want to debug a libtool generated executable without installing required libraries, you have to enter the following command: > "libtools --mode=execute gdb executable_script" Libtool creates an executable script and the real executable is located in hidden subdirectory ".libs". The problem is that eclipse debug launcher expects a binary file and does not allow to select a script to debug. Reproducible: Always
*** Bug 327458 has been marked as a duplicate of this bug. ***
Note that there is the very same problem also with _Run configuration_ and with _Profile Configuration_ for a libtool-linked executable. The executable_script cannot be given as the executable as it is not recognized as an executable. If the true executables in the .libs subfolder is picked, then all necessary environment variables, e.g. under linux LD_LIBRARY_PATH, are not set -- which the executable_script otherwise would do -- and shared libraries might be missing, resulting in a failure and not in a run. For Profile configurations one might like to use valgrind (via Linux Tools-plugin) which also needs the "libtool --mode=execute" prefixed. In this dialog a prefix to the executable cannot be given (as is not possible for Run configurations) and also the script is not recognized as an executable.
(In reply to comment #2) > Note that there is the very same problem also with _Run configuration_ and with > _Profile Configuration_ for a libtool-linked executable. > > The executable_script cannot be given as the executable as it is not recognized > as an executable. If the true executables in the .libs subfolder is picked, > then all necessary environment variables, e.g. under linux LD_LIBRARY_PATH, are > not set -- which the executable_script otherwise would do -- and shared > libraries might be missing, resulting in a failure and not in a run. > > For Profile configurations one might like to use valgrind (via Linux > Tools-plugin) which also needs the "libtool --mode=execute" prefixed. In this > dialog a prefix to the executable cannot be given (as is not possible for Run > configurations) and also the script is not recognized as an executable. To me this is a very big short coming of using the Autotools with Eclipse. While the Autotools project has made big leaps forwards in integrating Eclipse with the GNU tooling (my big, big thanks guys), the inability to debug a simple binary built with libtool means that as a user I'm forced to go elsewhere. I'm using the latest CDT (Eclipse Indigo) and the suggested trick of specifying "libtool --mode=execute gdb" doesn't work. Is there a plan to fix this bug soon?
It is now 2013, approximately 2.5 years from the initial filing of this bug report. Please either assign it or mark it as refused so that those of us who need this functionality will know that Eclipse CDT is not the tool for us.
*** Bug 252266 has been marked as a duplicate of this bug. ***
It would be very nice for the maintainer(s) to clarify their intentions regarding libtool execution and debugging.
(In reply to comment #6) > It would be very nice for the maintainer(s) to clarify their intentions > regarding libtool execution and debugging. I'm adding Jeff in CC since I think libtool is commonly used with Autotools projects, maybe he knows of a workaround for this? (Sorry for the spam) The project often keeps bugs like this one open in case someone from the community wants to contribute the feature. It's very rare that enhancements are "refused" and the corresponding bugs closed. Unfortunately, it doesn't look like anyone from the community (committers and users included) have found the time or have the motivation to implement this feature (so far!). If you're feeling up to it, you can try to modify your own CDT. Sometimes it can be fairly easy to make a quick and dirty fix that will be good enough for you and then you can to try to make a clean one that will get accepted into CDT. http://wiki.eclipse.org/Getting_started_with_CDT_development
Well there is a workaround: instead of "executable" you use ".libs/executable", which is the actual executable. but it won't find the, sometimes, required local libraries. So you will need to add "LD_LIBRARY_PATH=$(resource_loc:/project/path/to/lib/.libs" in addition. of course if you system already uses LD_LIBRARY_PATH you will need to extend instead of set. also LD_LIBRARY_PATH will only work on systems, like linux, which actually use this variable. other systems might use other environment variables for locating shared libraries.
(In reply to Jens Reimann from comment #8) > Well there is a workaround: > > instead of "executable" you use ".libs/executable", which is the actual > executable. but it won't find the, sometimes, required local libraries. So > you will need to add > "LD_LIBRARY_PATH=$(resource_loc:/project/path/to/lib/.libs" in addition. of > course if you system already uses LD_LIBRARY_PATH you will need to extend > instead of set. > > also LD_LIBRARY_PATH will only work on systems, like linux, which actually > use this variable. other systems might use other environment variables for > locating shared libraries. Yes. But this should be done by the wrapper scripts for us. Hope that support for libtool will be available.
