[Bug bootstrap/37660] New: Error Building libssp, recent update

[Bug bootstrap/37660] New: Error Building libssp, recent update

[mckelvey at maskull dot com]

$ uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

User@MCKELVEY-XP ~/cvsroot/gcc-obj
$ g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --disable-win32-registry
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20080826 (experimental) (GCC) 

User@MCKELVEY-XP ~/cvsroot/gcc-obj
$ alias CONFIGURECVS
alias CONFIGURECVS='/cygdrive/f/Home/cvsroot/gcc/configure     --verbose
--enable-threads --disable-nls     --disable-win32-registry
--enable-languages=c,c++ 2>&1 | tee clog'

User@MCKELVEY-XP ~/cvsroot/gcc-obj
$ alias BUILD
alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g
-O'\''     CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\''     bootstrap 2>&1 |
tee log'

I believe this is in stage 3:

libtool: compile:  /cygdrive/f/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include
-isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I.
-I/cygdrive/f/Home/cvsroot/gcc/libssp -I. -Wall -g -O2 -MT vsprintf-chk.lo -MD
-MP -MF .deps/vsprintf-chk.Tpo -c
/cygdrive/f/Home/cvsroot/gcc/libssp/vsprintf-chk.c -o vsprintf-chk.o >/dev/null
2>&1
/bin/sh ./libtool --tag=CC --mode=link
/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include
-isystem /usr/local/i686-pc-cygwin/sys-include -Wall -g -O2     -o libssp.la
-rpath /usr/local/lib -version-info `grep -v '^#'
/cygdrive/f/Home/cvsroot/gcc/libssp/libtool-version`
-Wl,--version-script=/cygdrive/f/Home/cvsroot/gcc/libssp/ssp.map -no-undefined
ssp.lo gets-chk.lo memcpy-chk.lo memmove-chk.lo mempcpy-chk.lo memset-chk.lo
snprintf-chk.lo sprintf-chk.lo stpcpy-chk.lo strcat-chk.lo strcpy-chk.lo
strncat-chk.lo strncpy-chk.lo vsnprintf-chk.lo vsprintf-chk.lo  
libtool: link: /cygdrive/f/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include
-isystem /usr/local/i686-pc-cygwin/sys-include -shared  .libs/ssp.o
.libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o
.libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o
.libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o
.libs/vsnprintf-chk.o .libs/vsprintf-chk.o   
-Wl,--version-script=/cygdrive/f/Home/cvsroot/gcc/libssp/ssp.map   -o
.libs/cygssp-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libssp.dll.a
Creating library file: .libs/libssp.dll.a.libs/ssp.o: In function `fail':
/cygdrive/f/Home/cvsroot/gcc/libssp/ssp.c:109: undefined reference to
`___chkstk'
.libs/gets-chk.o: In function `__gets_chk':
/cygdrive/f/Home/cvsroot/gcc/libssp/gets-chk.c:66: undefined reference to
`___chkstk'
collect2: ld returned 1 exit status

make[3]: *** [libssp.la] Error 1
make[3]: Leaving directory
`/cygdrive/f/Home/cvsroot/gcc-obj/i686-pc-cygwin/libssp'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/cygdrive/f/Home/cvsroot/gcc-obj/i686-pc-cygwin/libssp'
make[1]: *** [all-target-libssp] Error 2
make[1]: Leaving directory `/cygdrive/f/Home/cvsroot/gcc-obj'
make: *** [bootstrap] Error 2


-- 
           Summary: Error Building libssp, recent update
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mckelvey at maskull dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] Error Building libssp, recent update

[mckelvey at maskull dot com]

------- Comment #1 from mckelvey at maskull dot com  2008-11-29 18:59 -------
Still getting this bootstrap error, as of yesterday's update.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] Error Building libssp, recent update

[piotr dot wyderski at gmail dot com]

------- Comment #2 from piotr dot wyderski at gmail dot com  2009-01-14 15:20 -------
Still happens on Cygwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
            Summary|Error Building libssp,      |[4.4 Regression] Error
                   |recent update               |Building libssp, recent
                   |                            |update
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dannysmith at users dot sourceforge dot net]

------- Comment #3 from dannysmith at users dot sourceforge dot net  2009-01-15 02:39 -------
I believe that this failure reflects the fact that PE_COFF dll's do not allow
undefined symbols. Because of that, the rule to decide shared vs static libgcc 
in  gcc.c init_gcc_spec, namely the case for building a shared lib:
        "%{shared:", shared_name, "}"
is not quite right.   It should be (I think)
       "%{shared:", shared_name, , static_name "}"
However, since a shared libgcc is a new thing on cygwin and mingw, it may be
better for this release to actually require an explicit -shared-libgcc to get
the shared lib. That is what mingw32 does, by defining its own
REAL_LIBGCC_SPEC.

Does this patch fix the problem for you?

Index: config/i386/cygwin.h
===================================================================
--- config/i386/cygwin.h        (revision 143259)
+++ config/i386/cygwin.h        (working copy)
@@ -49,9 +49,17 @@
    GCC without making a new CYGWIN.DLL, so we leave it.  Profiling is handled
    by calling the init function from main.  */

-#undef LIBGCC_SPEC
-#define LIBGCC_SPEC \
-  "%{mno-cygwin: %{mthreads:-lmingwthrd} -lmingw32} -lgcc      \
+#
+#ifdef ENABLE_SHARED_LIBGCC
+#define SHARED_LIBGCC_SPEC "%{shared-libgcc:-lgcc_s}
%{!shared-libgcc:-lgcc_eh}"
+#else
+#define SHARED_LIBGCC_SPEC /*empty*/
+#endif
+#undef REAL_LIBGCC_SPEC
+#define REAL_LIBGCC_SPEC \
+  "%{mno-cygwin: %{mthreads:-lmingwthrd} -lmingw32} \
+   "SHARED_LIBGCC_SPEC" \
+   -lgcc \
    %{mno-cygwin:-lmoldname -lmingwex -lmsvcrt}"

 /* We have to dynamic link to get to the system DLLs.  All of libc, libm and


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dannysmith at users dot
                   |                            |sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #4 from dave dot korn dot cygwin at gmail dot com  2009-01-15 19:08 -------
  I've just run into this problem too.

  In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib.  I'm not sure why he didn't
do this in the committed version, but it has the effect that you have to link
against the static libgcc as well as the shared one in order to let it fill out
any missing references.  I'm not sure I'm entirely comfortable with that,
although I can't think of any obvious problem, but it seems wrong to link
against such a duplicated body of code to me, and I think I'd prefer the import
lib solution for cygwin's compiler.  (We want -shared-libgcc as the default,
for greater unixness).

  In a way, there's an impedance mismatch in the libgcc build system; you can
add new functions per-target to the static library, by listing them in the
target makefile fragment, but there's no similar target fragment to let you
define extra exports in the libgcc mapfile/version script.

  I'm going to prepare a patch that revises shared libgcc building.  I'll put
it in the cygwin-specific fragment as an override of the defaults from the
shared fragment, and it's probably going to do more than just fix chkstk/ctors,
so it won't be suitable for mingw, but the mingw team might or might not want
to consider doing the same.

  BTW someone who has admin powers should set confirm this bug, it's definitely
real! :)

  cheers,
    DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dannysmith at users dot sourceforge dot net]

------- Comment #5 from dannysmith at users dot sourceforge dot net  2009-01-16 07:14 -------
(In reply to comment #4)
>   I've just run into this problem too.
>   In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
> chkstk.o and placed them whole into the import lib.  I'm not sure why he didn't
> do this in the committed version, but it has the effect that you have to link
> against the static libgcc as well as the shared one in order to let it fill out
> any missing references.  I'm not sure I'm entirely comfortable with that,
> although I can't think of any obvious problem, but it seems wrong to link
> against such a duplicated body of code to me, and I think I'd prefer the import
> lib solution for cygwin's compiler. 


If you look at the (static) libgcc.a,  when shared libs are enabled, it
contains only symbols that are not exported from the shared dll. Only the
'API-stable' symbols are exported.  That is a good thing.  So the libgcc.a code
 does not duplicate any code in libgcc_s.[a|dll].


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-16 07:14:38
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #6 from dave dot korn dot cygwin at gmail dot com  2009-01-16 13:41 -------
(In reply to comment #5)

> If you look at the (static) libgcc.a,  when shared libs are enabled, it
> contains only symbols that are not exported from the shared dll. Only the
> 'API-stable' symbols are exported.  That is a good thing.  So the libgcc.a code
>  does not duplicate any code in libgcc_s.[a|dll].

  Sorry Danny, I don't understand.  I think what you're saying is that

    shared linking: libgcc_s.dll.a + libgcc.a

supplies the same overall set of symbols as

    static linking: libgcc_eh.a + libgcc.a

since if libgcc.a only contains stuff that is not exported from the DLL, then
-static-libgcc would fail - unless everything that is exported from the DLL is
available statically in libgcc_eh.a, which implies that the DLL could only
export the libgcc_eh functions?  I must have a misunderstanding somewhere. 
Also, I have been unable to verify your explanation.  In my current build
directory:

/gnu/gcc/obj-ng-fix $ nm prev-i686-pc-cygwin/libgcc/libgcc.a  | grep " T " | cu
t -d' ' -f3 > static-lib.txt
/gnu/gcc/obj-ng-fix $ nm prev-i686-pc-cygwin/libgcc/shlib/libgcc_s.dll.a  | gre
p " T " | cut -d' ' -f3 > import-lib.txt
/gnu/gcc/obj-ng-fix $ cat static-lib.txt import-lib.txt | sort | uniq -d | wc
     60      60     713
/gnu/gcc/obj-ng-fix $ cat static-lib.txt import-lib.txt | sort | uniq -u | wc
     37      37     812
/gnu/gcc/obj-ng-fix $

there are 60 common functions and 37 unique ones - the unique ones are indeed
the contents of libgcc_eh, plus these:

___chkstk
___eprintf
___gcc_bcmp
___gnat_default_lock
___gnat_default_unlock
___gnat_install_locks
___gthread_active_p
___gthread_mutex_lock
___gthread_mutex_unlock
___udiv_w_sdiv
__alloca

which are only in the static libs at all.

  Should I have understood you to mean that only the API-stable symbols are not
duplicated?  Or only the EH-related symbols?

  cheers,
    DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #7 from dave dot korn dot cygwin at gmail dot com  2009-01-18 05:57 -------
Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view)
Move _ctors* and _chkstk* to import lib

Danny, this is the approach that I think I'd like to take for Cygwin; what do
you think about doing it this way?  I'm currently testing a full bootstrap
using this patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dannysmith at users dot sourceforge dot net]

------- Comment #8 from dannysmith at users dot sourceforge dot net  2009-01-19 04:22 -------
(In reply to comment #7)
> Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> Move _ctors* and _chkstk* to import lib
> 
> Danny, this is the approach that I think I'd like to take for Cygwin; what do
> you think about doing it this way?  

On mingw we would also need to copy gthr-win32.o and __main.o into implib as
well.
It just seems simpler to follow the logic in init_gcc_spec with the
modification forced by the requirement for no-undefined-symbols when building a
dll.

Note that with your patch, init_gcc_spec will still link in the static libgcc
when building an .exe (ie the !shared case)

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #9 from dave dot korn dot cygwin at gmail dot com  2009-01-19 04:54 -------
(In reply to comment #8)
> (In reply to comment #7)
> > Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> > Move _ctors* and _chkstk* to import lib
> > 
> > Danny, this is the approach that I think I'd like to take for Cygwin; what do
> > you think about doing it this way?  
> 
> On mingw we would also need to copy gthr-win32.o and __main.o into implib as
> well.

  I just realised that I forgot --enable-threads when I configured, I'd
presumably need to do the same.

> It just seems simpler to follow the logic in init_gcc_spec with the
> modification forced by the requirement for no-undefined-symbols when building a
> dll.
> 
> Note that with your patch, init_gcc_spec will still link in the static libgcc
> when building an .exe (ie the !shared case)

  Ah, but nothing will be pulled in from it.

  However, on further thought, and specifically considering that there's no
pic/non-pic difference on windows, meaning that %.o and %_s.o are completely
identical, I guess I'm not worried about filling in from the static library any
more.  I'll roll up a new patch.

  cheers,
    DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[mckelvey at maskull dot com]

------- Comment #10 from mckelvey at maskull dot com  2009-01-19 22:29 -------
(In reply to comment #7)
> Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> Move _ctors* and _chkstk* to import lib
> 
> Danny, this is the approach that I think I'd like to take for Cygwin; what do
> you think about doing it this way?  I'm currently testing a full bootstrap
> using this patch.
> 

This patch works for Cygwin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #11 from dave dot korn dot cygwin at gmail dot com  2009-01-20 04:32 -------
Created an attachment (id=17151)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151&action=view)
Fill out missing syms from shared libgcc using static libgcc archive.

(In reply to comment #10)
> (In reply to comment #7)
> > Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> > Move _ctors* and _chkstk* to import lib

> This patch works for Cygwin.

:-)  Thanks for testing that.  I'm actually going to submit /this/ patch for
inclusion in mainline, once it's finished bootstrapping and testing; Danny is
right that this is just the simplest way to go.

  cheers,
    DaveK


-- 

dave dot korn dot cygwin at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17132|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[davek at gcc dot gnu dot org]

------- Comment #12 from davek at gcc dot gnu dot org  2009-01-21 19:20 -------
Subject: Bug 37660

Author: davek
Date: Wed Jan 21 19:20:08 2009
New Revision: 143552

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143552
Log:
        PR bootstrap/37660
        * config/i386/cygwin.h (SHARED_LIBGCC_SPEC):  New helper macro.
        (LIBGCC_SPEC):  Don't define.
        (REAL_LIBGCC_SPEC):  Define instead, using SHARED_LIBGCC_SPEC.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/cygwin.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[billingd at gcc dot gnu dot org]

------- Comment #13 from billingd at gcc dot gnu dot org  2009-01-24 08:23 -------
Confirmed as requested at comment #4.


-- 

billingd at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2009-01-16 07:14:38         |2009-01-24 08:23:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2009-01-24 16:56 -------
Can this be closed now?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #15 from dave dot korn dot cygwin at gmail dot com  2009-01-24 18:20 -------
[ David B. CC'd in for clarification requested ]

I'm under the impression that the bug is fixed now, so no objections from me.

I'm not sure why David B. just confirmed it though, I meant "Set the bug to the
NEW state from UNCONFIRMED", which Danny did some time ago.  David, do you mean
that you are still able to produce the bug from SVN HEAD?


-- 

dave dot korn dot cygwin at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |billingd at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[billingd at gcc dot gnu dot org]

------- Comment #16 from billingd at gcc dot gnu dot org  2009-01-24 23:13 -------
Just ignore my post at comment #13 to update the status.  Sorry for the noise. 
I should have read to the bottom of the PR before acting.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #17 from dave dot korn dot cygwin at gmail dot com  2009-01-24 23:15 -------
(In reply to comment #16)
> Just ignore my post at comment #13 to update the status.  Sorry for the noise. 
> I should have read to the bottom of the PR before acting.
> 

That's ok, thanks for clearing it up.  Jakub, please feel free to close this
bug RESO FIXE anytime.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

------- Comment #18 from dave dot korn dot cygwin at gmail dot com  2009-01-24 23:22 -------
(In reply to comment #17)
> (In reply to comment #16)
> > Just ignore my post at comment #13 to update the status.  Sorry for the noise. 
> > I should have read to the bottom of the PR before acting.
> > 
> 
> That's ok, thanks for clearing it up.  Jakub, please feel free to close this
> bug RESO FIXE anytime.

Or even better, James, are you still there?  As reporter you should have the
requisite permissions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[mckelvey at maskull dot com]

------- Comment #19 from mckelvey at maskull dot com  2009-01-25 01:21 -------
Resolved and fixed.


-- 

mckelvey at maskull dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660