Bug 1614755 - libtool --mode execute gdb
Summary: libtool --mode execute gdb
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: libtool
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-10 10:50 UTC by Marc-Andre Lureau
Modified: 2018-08-17 08:41 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-08-17 04:20:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
log (42.96 KB, text/plain)
2018-08-14 12:38 UTC, Marc-Andre Lureau
no flags Details

Description Marc-Andre Lureau 2018-08-10 10:50:44 UTC
I am running fedora 28, libtool-2.4.6-24.fc28.x86_64

Not long ago (f27?), I used to be able to debug programs with

libtool --mode=execute gdb --args src/foo

Now I get:

/usr/bin/libtool: line 3123: src/.libs/foo_ltshwrapper: No such file or directory


thanks

Comment 1 Pavel Raiskup 2018-08-13 05:47:35 UTC
(In reply to Marc-Andre Lureau from comment #0)
> Now I get:
> /usr/bin/libtool: line 3123: src/.libs/foo_ltshwrapper: No such file or
> directory

I can not reproduce in my projects.  Can you please provide self-contained
small reproducer?

Comment 2 Marc-Andre Lureau 2018-08-14 12:38:03 UTC
Created attachment 1475834 [details]
log

Hi Pavel,

Sorry I haven't been able to reproduce so far with a small project. And stripping down virt-viewer isn't simple.

Do you have a clue by looking at that bash log?

Comment 3 Pavel Raiskup 2018-08-15 05:25:51 UTC
The thing is:

+ case $file in
+ func_ltwrapper_script_p src/remote-viewer

This should succeed normally, but it falls back to ...

+ test -f src/remote-viewer
+ /usr/bin/dd bs=4096 count=1
+ func_generated_by_libtool_p
+ /usr/bin/grep '^# Generated by .*libtool'
+ func_ltwrapper_executable_p src/remote-viewer

.. this ^^^.

+ func_ltwrapper_exec_suffix=
+ case $1 in
+ func_ltwrapper_exec_suffix=.exe
+ /usr/bin/grep '%%%MAGIC EXE variable%%%' src/remote-viewer.exe
+ func_ltwrapper_scriptname src/remote-viewer

... what's weird, this succeeds.

Comment 4 Pavel Raiskup 2018-08-15 05:49:49 UTC
I still think this is normally built Linux program, and no cross-compilation
or similar is done.

Comment 5 Pavel Raiskup 2018-08-15 05:50:41 UTC
I mean: s/I still think/I still assume/.

Comment 6 Marc-Andre Lureau 2018-08-16 13:33:52 UTC
(In reply to Pavel Raiskup from comment #3)
> The thing is:
> 
> + case $file in
> + func_ltwrapper_script_p src/remote-viewer
> 
> This should succeed normally, but it falls back to ...
> 
> + test -f src/remote-viewer
> + /usr/bin/dd bs=4096 count=1
> + func_generated_by_libtool_p
> + /usr/bin/grep '^# Generated by .*libtool'
> + func_ltwrapper_executable_p src/remote-viewer
> 
> .. this ^^^.
> 
> + func_ltwrapper_exec_suffix=
> + case $1 in
> + func_ltwrapper_exec_suffix=.exe
> + /usr/bin/grep '%%%MAGIC EXE variable%%%' src/remote-viewer.exe
> + func_ltwrapper_scriptname src/remote-viewer
> 
> ... what's weird, this succeeds.

ah ah..., I have .exe files laying around. Deleted them and problem is gone.

Obviously, it would be better if libtool didn't look at thoses when doing cross-compilation.

thanks

Comment 7 Pavel Raiskup 2018-08-17 04:20:01 UTC
> it would be better if libtool didn't look at thoses when doing cross-compilation.

Am I right that you mean when *not* doing cross compilation?

Comment 8 Marc-Andre Lureau 2018-08-17 08:41:40 UTC
(In reply to Pavel Raiskup from comment #7)
> > it would be better if libtool didn't look at thoses when doing cross-compilation.
> 
> Am I right that you mean when *not* doing cross compilation?

yep ;)


Note You need to log in before you can comment on or make changes to this bug.