Feature Requests item #1785282, was opened at 2007-08-31 02:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=1785282&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Martijn Wargers (martijnw22)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need an IOfficeAntiVirus definition
Initial Comment:
See Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=394272
The latest builds of Firefox support virusscanning of downloaded files.
But that uses some MSVC specific code that is in the platform SDK.
But afaik, there is no equivalent code in mingw that supports IOfficeAntiVirus definition and stuff.
The header file of the Microsoft SDK that makes this possible is msoav.h.
I'm currently trying to disable this code for mingw builds, so that mingw users at least don't get build errors while compiling Firefox, but ideally that should not be necessary, of course.
This is the link to the msdn documentation:
http://msdn2.microsoft.com/en-us/library/ms537369.aspx
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=1785282&group_id=2435

Bugs item #1784372, was opened at 2007-08-29 19:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784372&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joachim Eibl (joachim99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under Vista many files are not found
Initial Comment:
I installed MinGW-5.1.3.exe on Vista Home Premium and for comparison on XP.
I tried to build KDiff3-0.9.92 (kdiff3.sf.net) for Qt4. (I'm the author.)
On XP everything works as expected.
When building the kdiff3.exe on Vista there is the problem that windres.exe tells me:
gcc: installation problem, cannot exec `cc1': No such file or directory
After adding the path "C:\MinGW\libexec\gcc\mingw32\3.4.2" I can finish compiling and linking.
Then I proceed to building the dll diff_ext_for_kdiff3.
Again under XP it works fine but under Vista the final step from dllwrap.exe is the linking via this command:
ld --dll -Bdynamic -e _DllMainCRTStartup@... -o diff_ext_for_kdiff3.dll -s dllcrt2.o crtbegin.o -base-file ./cca04840.base -e _DllMainCRTStartup@... --image-base 0x62A40000 class_factory.o diff_ext.o server.o diff_ext_for_kdiff3.res -luuid -lole32 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt crtend.o
Result:
ld: dllcrt2.o: No such file: No such file or directory
I add the full path names for everything and get it to link via this command:
ld --dll -Bdynamic -e _DllMainCRTStartup@... -o diff_ext_for_kdiff3.dll -s -Lc:\mingw\lib -LC:\MinGW\lib\gcc\mingw32\3.4.2 c:\mingw\lib\dllcrt2.o C:\MinGW\lib\gcc\mingw32\3.4.2\crtbegin.o --base-file ./cca04224.base -e _DllMainCRTStartup@... --image-base 0x62A40000 class_factory.o diff_ext.o server.o diff_ext_for_kdiff3.res -luuid -lole32 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt C:\MinGW\lib\gcc\mingw32\3.4.2\crtend.o
Why are ld and windres not able to figure out the paths for themselves under Vista as they can under XP?
Best regards,
Joachim
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784372&group_id=2435

Bugs item #1784000, was opened at 2007-08-29 09:07
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784000&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: mario baumann (baumann0)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong time on german windows with date.exe + ls.exe
Initial Comment:
Hi All,
on my german windows 2000 professional (5.00.2195) the msys binaries date.exe + ls.exe + ...
( from MSYS-1.0.10.exe, sha1sum =>
510fcfa923833073bc55302913739e25b909e66a )
print always the UTC time instead of the local time.
If I set the TZ environment variable to UTC-2 both binaries working well.
With a english windows 2000 professional both binaries date.exe and ls.exe works perfect without TZ setting.
What's the problem?
Mario.
----------------------------------------------------------------------
>Comment By: Earnie Boyd (earnie)
Date: 2007-08-29 15:09
Message:
Logged In: YES
user_id=15438
Originator: NO
Since you have a method to get the correct time I'm not going to spend
time with this but feel free to chase it down and supply a patch. Setting
TZ is the common solution for this problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784000&group_id=2435

Bugs item #1784030, was opened at 2007-08-29 22:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784030&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Takashi Ono (t_ono)
Assigned to: Danny Smith (dannysmith)
Summary: linkage failure of bad_cast in libstdc++_s
Initial Comment:
In libstdc++_s.a in gcc-4.2.1-dw2-2, tinfo.o and tinfo2.o are included. I suppose
that they always have to be statically linked.
On the other hand, as class bad_cast is prefixed with _GLIBCXX_IMPORT in <typeinfo>,
client programs using the class require vtable import for the class from libstds++
and seem to fail in linkage here at my site.
Takashi Ono
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784030&group_id=2435

Bugs item #1784000, was opened at 2007-08-29 13:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784000&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mario baumann (baumann0)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong time on german windows with date.exe + ls.exe
Initial Comment:
Hi All,
on my german windows 2000 professional (5.00.2195) the msys binaries date.exe + ls.exe + ...
( from MSYS-1.0.10.exe, sha1sum =>
510fcfa923833073bc55302913739e25b909e66a )
print always the UTC time instead of the local time.
If I set the TZ environment variable to UTC-2 both binaries working well.
With a english windows 2000 professional both binaries date.exe and ls.exe works perfect without TZ setting.
What's the problem?
Mario.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1784000&group_id=2435

Bugs item #1782165, was opened at 2007-08-26 17:22
Message generated for change (Comment added) made by gressett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1782165&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Gressett (gressett)
Assigned to: Danny Smith (dannysmith)
Summary: Bug box when compiling Ada code
Initial Comment:
I get a bug box when compiling the Ada source in the attached file adafiles.txt. test2.adb produces the box when it is compiled.
background info:
OS version: Windows 2000 SP4
gcc version:
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure
--with-gcc
--enable-libgomp
--host=mingw32
--build=mingw32
--target=mingw32
--program-suffix=-dw2
--with-arch=i486
--with-tune=generic
--disable-werror
--prefix=/mingw
--with-local-prefix=/mingw
--enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada
--disable-win32-registry
--disable-sjlj-exceptions
--enable-libstdcxx-debug
--enable-cxx-flags=-fno-function-sections -fno-data-sections
--enable-version-specific-runtime-libs
--disable-bootstrap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)
ld version: not relevant, no linking attempted
MinGW version: 5.1.3
Build environment: Windows command-line (No MSYS)
Here is the bug box, produced with gcc -c test2.adb:
c:/mingw/bin/../libexec/gcc/mingw32/4.2.1-dw2/gnat1.exe -quiet -dumpbase test2.
adb -mtune=generic -march=i486 test2.adb -o test2.s
+===========================GNAT BUG DETECTED==============================+
| 4.2.1-dw2 (mingw32-2) (i386-pc-mingw32) Assert_Failure atree.adb:812 |
| Error detected at test2.adb:12:60 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==========================================================================+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
test2.adb
gwindows.ads
gwindows-types.ads
gwindows-xbase.ads
compilation abandoned
There are 5 ada files concatenated to form the ada source upload., but test2.adb (the main procedure) and gwindows-xbase.adb are the important files.
----------------------------------------------------------------------
>Comment By: David Gressett (gressett)
Date: 2007-08-27 11:21
Message:
Logged In: YES
user_id=135820
Originator: YES
I'm not sure if this is the same thing as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015.
"Assert_Failure atree.adb:812" suggests that my bug has something in
common with 29015, but the demo code for 29015 makes substantial use of Ada
2005 new features. My sample code is derived from GWindows source code that
is entirely Ada 95 and which compiles with the MinGW 3.4.5 Ada compiler.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2007-08-26 21:55
Message:
Logged In: YES
user_id=11494
Originator: NO
Is this same as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
?
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1782165&group_id=2435

Bugs item #1782165, was opened at 2007-08-26 17:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1782165&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Gressett (gressett)
Assigned to: Danny Smith (dannysmith)
Summary: Bug box when compiling Ada code
Initial Comment:
I get a bug box when compiling the Ada source in the attached file adafiles.txt. test2.adb produces the box when it is compiled.
background info:
OS version: Windows 2000 SP4
gcc version:
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure
--with-gcc
--enable-libgomp
--host=mingw32
--build=mingw32
--target=mingw32
--program-suffix=-dw2
--with-arch=i486
--with-tune=generic
--disable-werror
--prefix=/mingw
--with-local-prefix=/mingw
--enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada
--disable-win32-registry
--disable-sjlj-exceptions
--enable-libstdcxx-debug
--enable-cxx-flags=-fno-function-sections -fno-data-sections
--enable-version-specific-runtime-libs
--disable-bootstrap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)
ld version: not relevant, no linking attempted
MinGW version: 5.1.3
Build environment: Windows command-line (No MSYS)
Here is the bug box, produced with gcc -c test2.adb:
c:/mingw/bin/../libexec/gcc/mingw32/4.2.1-dw2/gnat1.exe -quiet -dumpbase test2.
adb -mtune=generic -march=i486 test2.adb -o test2.s
+===========================GNAT BUG DETECTED==============================+
| 4.2.1-dw2 (mingw32-2) (i386-pc-mingw32) Assert_Failure atree.adb:812 |
| Error detected at test2.adb:12:60 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==========================================================================+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
test2.adb
gwindows.ads
gwindows-types.ads
gwindows-xbase.ads
compilation abandoned
There are 5 ada files concatenated to form the ada source upload., but test2.adb (the main procedure) and gwindows-xbase.adb are the important files.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1782165&group_id=2435

Bugs item #1775118, was opened at 2007-08-16 12:55
Message generated for change (Comment added) made by jdpipe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Pye (jdpipe)
Assigned to: Cesar Strauss (cstrauss)
Summary: /etc/inputrc isn't read at msys startup
Initial Comment:
With MSYS, I find that /etc/inputrc doesn't get read, even if ~/.inputrc is missing.
I think that whereever ~/.inputrc is being read, there should be a fallback added so that /etc/inputrc is used.
And then /etc/inputrc should be installed by default to contain the necessary keybindings so that RXVT behaves as it should be default, with the HOME and END keys working as they should.
This would make a huge difference to the usability of MSYS for new users, who don't know about adding the .inputrc file.
Cheers
JP
john@... ~
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
88064 Tue Sep 21 19:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 17:41:43 2006 /mingw/bin/ld.exe
HOME=/home/john
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=/C/GTK/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/GTK/bin:/c/T
cl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/
c/Program Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts
:/c/Program Files/GnuWin32/bin:/mingw/local/swigwin-1.3.31/:/c/P
rogram Files/NSIS
----------------------------------------------------------------------
>Comment By: John Pye (jdpipe)
Date: 2007-08-23 14:58
Message:
Logged In: YES
user_id=849068
Originator: YES
For the record, I made an enquiry on the BASH mailing list, and I was told
that current versions of READLINE do the job properly, reading /etc/inputrc
if ~/.inputrc is absent. So I guess the best option might be to update
MinGW's version of READLINE, if that is possible (and assuming it's not
already using the latest version)
----------------------------------------------------------------------
Comment By: John Pye (jdpipe)
Date: 2007-08-17 15:48
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi Cesar,
If you are able to fix this, that would be BRILLIANT. This is my #1
annoyance with MSYS, which is otherwise really great.
Just one thing to note about inputrc, I've noticed that 'vim' doesn't
behave properly with the begin/end keys, even if .inputrc is set correctly.
Might be that VIM needs to be tweaked also, not sure.
Cheers
JP
----------------------------------------------------------------------
Comment By: Cesar Strauss (cstrauss)
Date: 2007-08-17 12:30
Message:
Logged In: YES
user_id=1369729
Originator: NO
Hi, John
> With MSYS, I find that /etc/inputrc doesn't get read,
> even if ~/.inputrc is missing.
I believe this is to be expected. From the bash manual:
http://www.gnu.org/software/bash/manual/bashref.html#SEC98
"Any user can customize programs that use Readline by
putting commands in an inputrc file, conventionally in
his home directory. The name of this file is taken from
the value of the shell variable INPUTRC. If that variable
is unset, the default is `~/.inputrc'."
Note that /etc/inputrc is not mentioned at all.
> And then /etc/inputrc should be installed by default to
> contain the necessary keybindings so that RXVT behaves
> as it should be default, with the HOME and END keys
> working as they should.
Yes, it would be a nice feature.
I see two ways for this to work:
a) Install a /etc/inputrc by default. Then, when the user's home directory
is created, create a ~/.inputrc file with the following content: "$include
/etc/inputrc"
b) Place a default inputrc in the /etc/skel directory. When the user's
home directory is created, copy it to ~/.inputrc.
> Are you saying it's fixed in the snapshot, or are you saying
> that you'd like me to try the new version to confirm that the
> bug is still present?
Please wait a little longer. I'll see if I can include this feature in the
next MSYS snapshot.
Regards,
Cesar
----------------------------------------------------------------------
Comment By: John Pye (jdpipe)
Date: 2007-08-17 10:04
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi,
Are you saying it's fixed in the snapshot, or are you saying that you'd
like me to try the new version to confirm that the bug is still present?
JP
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2007-08-16 23:51
Message:
Logged In: YES
user_id=15438
Originator: NO
Please try with the recent snapshot.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435

Patches item #1778949, was opened at 2007-08-21 22:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=1778949&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: aurisc4 (aurisc4)
Assigned to: Earnie Boyd (earnie)
Summary: Executable to replace msys.bat
Initial Comment:
msys.exe: a replacement for msys.bat
Program reads configuration from msys.config, so allowing user to change startup parametters without editing msys.bat.
Changelog entries included into files themselves.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=1778949&group_id=2435

Bugs item #1775487, was opened at 2007-08-17 02:30
Message generated for change (Comment added) made by dannysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gdb
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Doug Schaefer (dougschaefer)
Assigned to: Chris Johns (cjohns)
Summary: dw2 - setting line breakpoints confused by backslash in path
Initial Comment:
Steps to reproduce:
- Create a simple main.cpp file with a main.
- Create a subdirectory in the same directory.
- Compile main.cpp from that directory using a backslash in the path, i.e. gcc -c ..\main.cpp, using the dw2-2 version of gcc.
- Debug the resulting app and try to set a breakpoint at main.cpp:10.
- gdb reports that there is no line 10 in main.cpp.
Debugging gdb, in lookup_symtab, I see it returning two symbol tables, one for ../main.cpp and one for ..\main.cpp. Only one of them has an associated linetable. Unfortunatley gdb only checks one of them and picks the wrong one.
I'm not sure why there are two entries. The psymtab in dwarf2_psymtab_to_symtab seems to have a dependency between the two files which is why I think you get the two entries. Now is this a problem in the dwarf info generated by gcc, or a problem with gdb using that info, I'm not sure.
----------------------------------------------------------------------
>Comment By: Danny Smith (dannysmith)
Date: 2007-08-18 13:45
Message:
Logged In: YES
user_id=11494
Originator: NO
"This points at the dwarf info creation in gcc. Somewhere the slash is
getting converted over there."
Yes, this happens in gcc's toplev.c set_src_pwd/get_src_pwd which are used
by dwarf2 to access the src dir string.
I have a patch that canonicalizes the src_pwd to always use forward
slashes. This is the right thing for dwarf2 output for gdb, but I need to
check other users of src_pwd.
Chris, assign this to me if you think the fix should be in gcc.
Danny
----------------------------------------------------------------------
Comment By: Doug Schaefer (dougschaefer)
Date: 2007-08-18 07:48
Message:
Logged In: YES
user_id=818814
Originator: YES
Digging deeper with the debugger, I am finding that the file name in the
dwarf lineinfo is using the forward slash. Thus when the we go to load the
lineinfo with the name using the backslash, it doesn't find it.
This points at the dwarf info creation in gcc. Somewhere the slash is
getting converted over there.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435

Bugs item #1775487, was opened at 2007-08-16 09:30
Message generated for change (Comment added) made by dougschaefer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gdb
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Doug Schaefer (dougschaefer)
Assigned to: Chris Johns (cjohns)
Summary: dw2 - setting line breakpoints confused by backslash in path
Initial Comment:
Steps to reproduce:
- Create a simple main.cpp file with a main.
- Create a subdirectory in the same directory.
- Compile main.cpp from that directory using a backslash in the path, i.e. gcc -c ..\main.cpp, using the dw2-2 version of gcc.
- Debug the resulting app and try to set a breakpoint at main.cpp:10.
- gdb reports that there is no line 10 in main.cpp.
Debugging gdb, in lookup_symtab, I see it returning two symbol tables, one for ../main.cpp and one for ..\main.cpp. Only one of them has an associated linetable. Unfortunatley gdb only checks one of them and picks the wrong one.
I'm not sure why there are two entries. The psymtab in dwarf2_psymtab_to_symtab seems to have a dependency between the two files which is why I think you get the two entries. Now is this a problem in the dwarf info generated by gcc, or a problem with gdb using that info, I'm not sure.
----------------------------------------------------------------------
>Comment By: Doug Schaefer (dougschaefer)
Date: 2007-08-17 14:48
Message:
Logged In: YES
user_id=818814
Originator: YES
Digging deeper with the debugger, I am finding that the file name in the
dwarf lineinfo is using the forward slash. Thus when the we go to load the
lineinfo with the name using the backslash, it doesn't find it.
This points at the dwarf info creation in gcc. Somewhere the slash is
getting converted over there.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435

Bugs item #1775118, was opened at 2007-08-16 12:55
Message generated for change (Comment added) made by jdpipe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Pye (jdpipe)
Assigned to: Cesar Strauss (cstrauss)
Summary: /etc/inputrc isn't read at msys startup
Initial Comment:
With MSYS, I find that /etc/inputrc doesn't get read, even if ~/.inputrc is missing.
I think that whereever ~/.inputrc is being read, there should be a fallback added so that /etc/inputrc is used.
And then /etc/inputrc should be installed by default to contain the necessary keybindings so that RXVT behaves as it should be default, with the HOME and END keys working as they should.
This would make a huge difference to the usability of MSYS for new users, who don't know about adding the .inputrc file.
Cheers
JP
john@... ~
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
88064 Tue Sep 21 19:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 17:41:43 2006 /mingw/bin/ld.exe
HOME=/home/john
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=/C/GTK/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/GTK/bin:/c/T
cl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/
c/Program Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts
:/c/Program Files/GnuWin32/bin:/mingw/local/swigwin-1.3.31/:/c/P
rogram Files/NSIS
----------------------------------------------------------------------
>Comment By: John Pye (jdpipe)
Date: 2007-08-17 15:48
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi Cesar,
If you are able to fix this, that would be BRILLIANT. This is my #1
annoyance with MSYS, which is otherwise really great.
Just one thing to note about inputrc, I've noticed that 'vim' doesn't
behave properly with the begin/end keys, even if .inputrc is set correctly.
Might be that VIM needs to be tweaked also, not sure.
Cheers
JP
----------------------------------------------------------------------
Comment By: Cesar Strauss (cstrauss)
Date: 2007-08-17 12:30
Message:
Logged In: YES
user_id=1369729
Originator: NO
Hi, John
> With MSYS, I find that /etc/inputrc doesn't get read,
> even if ~/.inputrc is missing.
I believe this is to be expected. From the bash manual:
http://www.gnu.org/software/bash/manual/bashref.html#SEC98
"Any user can customize programs that use Readline by
putting commands in an inputrc file, conventionally in
his home directory. The name of this file is taken from
the value of the shell variable INPUTRC. If that variable
is unset, the default is `~/.inputrc'."
Note that /etc/inputrc is not mentioned at all.
> And then /etc/inputrc should be installed by default to
> contain the necessary keybindings so that RXVT behaves
> as it should be default, with the HOME and END keys
> working as they should.
Yes, it would be a nice feature.
I see two ways for this to work:
a) Install a /etc/inputrc by default. Then, when the user's home directory
is created, create a ~/.inputrc file with the following content: "$include
/etc/inputrc"
b) Place a default inputrc in the /etc/skel directory. When the user's
home directory is created, copy it to ~/.inputrc.
> Are you saying it's fixed in the snapshot, or are you saying
> that you'd like me to try the new version to confirm that the
> bug is still present?
Please wait a little longer. I'll see if I can include this feature in the
next MSYS snapshot.
Regards,
Cesar
----------------------------------------------------------------------
Comment By: John Pye (jdpipe)
Date: 2007-08-17 10:04
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi,
Are you saying it's fixed in the snapshot, or are you saying that you'd
like me to try the new version to confirm that the bug is still present?
JP
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2007-08-16 23:51
Message:
Logged In: YES
user_id=15438
Originator: NO
Please try with the recent snapshot.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435

Bugs item #1775118, was opened at 2007-08-15 23:55
Message generated for change (Comment added) made by cstrauss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
>Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Pye (jdpipe)
Assigned to: Cesar Strauss (cstrauss)
Summary: /etc/inputrc isn't read at msys startup
Initial Comment:
With MSYS, I find that /etc/inputrc doesn't get read, even if ~/.inputrc is missing.
I think that whereever ~/.inputrc is being read, there should be a fallback added so that /etc/inputrc is used.
And then /etc/inputrc should be installed by default to contain the necessary keybindings so that RXVT behaves as it should be default, with the HOME and END keys working as they should.
This would make a huge difference to the usability of MSYS for new users, who don't know about adding the .inputrc file.
Cheers
JP
john@... ~
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
88064 Tue Sep 21 19:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 17:41:43 2006 /mingw/bin/ld.exe
HOME=/home/john
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=/C/GTK/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/GTK/bin:/c/T
cl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/
c/Program Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts
:/c/Program Files/GnuWin32/bin:/mingw/local/swigwin-1.3.31/:/c/P
rogram Files/NSIS
----------------------------------------------------------------------
>Comment By: Cesar Strauss (cstrauss)
Date: 2007-08-16 23:30
Message:
Logged In: YES
user_id=1369729
Originator: NO
Hi, John
> With MSYS, I find that /etc/inputrc doesn't get read,
> even if ~/.inputrc is missing.
I believe this is to be expected. From the bash manual:
http://www.gnu.org/software/bash/manual/bashref.html#SEC98
"Any user can customize programs that use Readline by
putting commands in an inputrc file, conventionally in
his home directory. The name of this file is taken from
the value of the shell variable INPUTRC. If that variable
is unset, the default is `~/.inputrc'."
Note that /etc/inputrc is not mentioned at all.
> And then /etc/inputrc should be installed by default to
> contain the necessary keybindings so that RXVT behaves
> as it should be default, with the HOME and END keys
> working as they should.
Yes, it would be a nice feature.
I see two ways for this to work:
a) Install a /etc/inputrc by default. Then, when the user's home directory
is created, create a ~/.inputrc file with the following content: "$include
/etc/inputrc"
b) Place a default inputrc in the /etc/skel directory. When the user's
home directory is created, copy it to ~/.inputrc.
> Are you saying it's fixed in the snapshot, or are you saying
> that you'd like me to try the new version to confirm that the
> bug is still present?
Please wait a little longer. I'll see if I can include this feature in the
next MSYS snapshot.
Regards,
Cesar
----------------------------------------------------------------------
Comment By: John Pye (jdpipe)
Date: 2007-08-16 21:04
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi,
Are you saying it's fixed in the snapshot, or are you saying that you'd
like me to try the new version to confirm that the bug is still present?
JP
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2007-08-16 10:51
Message:
Logged In: YES
user_id=15438
Originator: NO
Please try with the recent snapshot.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435

Bugs item #1775118, was opened at 2007-08-16 12:55
Message generated for change (Comment added) made by jdpipe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: Waiting User Response
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Pye (jdpipe)
Assigned to: Cesar Strauss (cstrauss)
Summary: /etc/inputrc isn't read at msys startup
Initial Comment:
With MSYS, I find that /etc/inputrc doesn't get read, even if ~/.inputrc is missing.
I think that whereever ~/.inputrc is being read, there should be a fallback added so that /etc/inputrc is used.
And then /etc/inputrc should be installed by default to contain the necessary keybindings so that RXVT behaves as it should be default, with the HOME and END keys working as they should.
This would make a huge difference to the usability of MSYS for new users, who don't know about adding the .inputrc file.
Cheers
JP
john@... ~
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
88064 Tue Sep 21 19:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 17:41:43 2006 /mingw/bin/ld.exe
HOME=/home/john
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=/C/GTK/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/GTK/bin:/c/T
cl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/
c/Program Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts
:/c/Program Files/GnuWin32/bin:/mingw/local/swigwin-1.3.31/:/c/P
rogram Files/NSIS
----------------------------------------------------------------------
>Comment By: John Pye (jdpipe)
Date: 2007-08-17 10:04
Message:
Logged In: YES
user_id=849068
Originator: YES
Hi,
Are you saying it's fixed in the snapshot, or are you saying that you'd
like me to try the new version to confirm that the bug is still present?
JP
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2007-08-16 23:51
Message:
Logged In: YES
user_id=15438
Originator: NO
Please try with the recent snapshot.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435

Bugs item #1775487, was opened at 2007-08-16 09:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gdb
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Doug Schaefer (dougschaefer)
Assigned to: Chris Johns (cjohns)
Summary: dw2 - setting line breakpoints confused by backslash in path
Initial Comment:
Steps to reproduce:
- Create a simple main.cpp file with a main.
- Create a subdirectory in the same directory.
- Compile main.cpp from that directory using a backslash in the path, i.e. gcc -c ..\main.cpp, using the dw2-2 version of gcc.
- Debug the resulting app and try to set a breakpoint at main.cpp:10.
- gdb reports that there is no line 10 in main.cpp.
Debugging gdb, in lookup_symtab, I see it returning two symbol tables, one for ../main.cpp and one for ..\main.cpp. Only one of them has an associated linetable. Unfortunatley gdb only checks one of them and picks the wrong one.
I'm not sure why there are two entries. The psymtab in dwarf2_psymtab_to_symtab seems to have a dependency between the two files which is why I think you get the two entries. Now is this a problem in the dwarf info generated by gcc, or a problem with gdb using that info, I'm not sure.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775487&group_id=2435

Bugs item #1775118, was opened at 2007-08-15 22:55
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
>Group: Waiting User Response
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: John Pye (jdpipe)
>Assigned to: Cesar Strauss (cstrauss)
Summary: /etc/inputrc isn't read at msys startup
Initial Comment:
With MSYS, I find that /etc/inputrc doesn't get read, even if ~/.inputrc is missing.
I think that whereever ~/.inputrc is being read, there should be a fallback added so that /etc/inputrc is used.
And then /etc/inputrc should be installed by default to contain the necessary keybindings so that RXVT behaves as it should be default, with the HOME and END keys working as they should.
This would make a huge difference to the usability of MSYS for new users, who don't know about adding the .inputrc file.
Cheers
JP
john@... ~
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.4.2 (mingw-special); targ=MINGW32
GNU ld version 2.16.91 20060119
789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
88064 Tue Sep 21 19:15:22 2004 /mingw/bin/gcc.exe
685568 Fri Jan 20 17:41:43 2006 /mingw/bin/ld.exe
HOME=/home/john
Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=msys
PATH=/C/GTK/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/GTK/bin:/c/T
cl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/
c/Program Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts
:/c/Program Files/GnuWin32/bin:/mingw/local/swigwin-1.3.31/:/c/P
rogram Files/NSIS
----------------------------------------------------------------------
>Comment By: Earnie Boyd (earnie)
Date: 2007-08-16 09:51
Message:
Logged In: YES
user_id=15438
Originator: NO
Please try with the recent snapshot.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775118&group_id=2435

Bugs item #1774356, was opened at 2007-08-14 22:14
Message generated for change (Comment added) made by techtonik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1774356&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW Installer
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: tibbalzdude (tibbalz)
Assigned to: Dave Murphy (wntrmute)
Summary: I tried to uninstall MinGW and it deleted a lot of files
Initial Comment:
I tried to uninstall MinGW and I noticed it said "deleting - songs/song.mp3" and the like, I pressed CTRL ALT DELETE as fast as I could and ended the uninstallation. I lost my almost all of the files under "My Documents" I am very upset. All I want is for you to know and if you could tell me why I lost all my files. (I had My Documents set as the folder to download MinGW to)
Please fix this or tell me what I did wrong. I downloaded the current version off of sourceforge
----------------------------------------------------------------------
Comment By: anatoly techtonik (techtonik)
Date: 2007-08-16 13:37
Message:
Logged In: YES
user_id=669020
Originator: NO
Thanks for bug report. If it is not too late for your files - you may try
to undelete them -
http://www.google.com/search?q=windows+file+recovery+freeware&hl=en
Do you remember which version of installer have you used? In 5.1.3 if you
choose option to just "Download" instead of "Download and install" you
won't be prompted for a place to download files, and all files will go
straight into the directory with installer. In case of "Download and
install" option the installer asks about "Install Location" and not about
"Download folder". In any case installer should have warned you about the
intention to install into existing and not empty directory. I think it will
be fixed in next release.
Sorry, and thanks again for filing this issue.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1774356&group_id=2435

Bugs item #1775333, was opened at 2007-08-16 19:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775333&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Takashi Ono (t_ono)
Assigned to: Danny Smith (dannysmith)
Summary: gcc-4.2.1-dw2-2 does not handle dllexport properly
Initial Comment:
gcc-4.2.1-dw2-2 seems to be ignoring dllexport attribute on uninitialized data.
__declspec(dllexport) int a;
does not work like gcc-3.x.x. The compiler does not emit the assembler directive.
__declspec(dllexport) int a=0;
seems to be OK.
Takashi Ono
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1775333&group_id=2435

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details