Issue 16528 - Make crashrep build and linking dependent from ENABLE_CRASHDUMP variable
Summary: Make crashrep build and linking dependent from ENABLE_CRASHDUMP variable
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 1.1 RC
Assignee: philipp.lohmann
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-07 09:30 UTC by hennes.rohling
Modified: 2010-11-10 17:10 UTC (History)
9 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hennes.rohling 2003-07-07 09:30:26 UTC
Linking against GTK+ should always be done dynamically. The needed GTK libraries
have to be shipped with OpenOffice.

-> Change linking of crash reporter
-> Install needed GTK libraries along with OpenOffice
-> Remove --use-static-gtk from configure script
Comment 1 hennes.rohling 2003-07-07 09:30:52 UTC
Target set.
Comment 2 khendricks 2003-07-07 14:12:32 UTC
Hi, .... Adding my 2 cents moved from Issue 15843 ... 
 
> It's a better option to ship the needed GTK libraries (LGPL) with OOo  
> and always link dynamically.  
> For OOo 1.1 RC all builds for Linux x86 and Solaris will be done by  
> SUN so we can provide a correct static linked version for download.  
    
This is a joke right?  Do you really want to add the gtk-+2.0 libs to the binary tarball  
people have to download (and all of the supporting libs too)?.    
  
That seems completely crazy to add such a build requirement for anything like a  
"crash reporter" that is hopefully never invoked.  
  
Please simply rewrite crashreporter to use a X11, Xt and Xaw and drop all this idea  
of including gtk+2.0 libs in the installer.  
  
PPC Linux will NOT be shipping any gtk-2.0 libs and therefore probably not  
crashreporter in the future either then.  
  
I will instead ifdef the code in sal/osl/unx/signal.c to rename the created stack trace  
tmp files to include something more amenable to users with full date and ask the user  
to manually forward those files with any ppc linux crashing bug report.  
  
Please do not add the gtk+2.0 libs as a build requirement.  
Please do not add them to the already huge size of the binary installer. 
 
AFAIK, there is no requirement to use the gtk libs anyplace else nor is there a plan to 
do so that has been agreed upon on the gsl list. 
 
Thanks, 
  
Kevin  
 
Comment 3 pavel 2003-07-07 15:38:06 UTC
+1, using GTK for something like crashrep is crazy.
I'm all for using text user interface instead and if not, Xaw is enough.

Kevin, if you want to have a tester for your patches, I'm ready.
Comment 4 hennes.rohling 2003-07-07 16:01:13 UTC
Accepted.
Comment 5 alex.thurgood 2003-07-07 17:05:11 UTC
Well it does seem to be a rather heft whack on the tarball size just
to have a graphical crash reporter. It is really necessary ? Why GTK ?

+1 for leaving it out and choosing something else that will work with
all versions of OOo.

Alex
Comment 6 fa 2003-07-07 17:42:18 UTC
Furthermore, how are the GTK+ libraries going to be included?  Manually by the 
creator at installer-creation time?  Copied from a local location by instsetoo?  Added 
as binaries to the tree like the Mozilla libraries?  Mac OS X cannot use any version 
GTK+ at this time, since none have been successfully ported, and we don't really want 
to deal with downloading all platforms' GTK+ libraries like we do with mozilla libs 
now, when we cannot even use them.

I like GTK+, but as Kevin says, this is overkill.

Dan
Comment 7 simonbr 2003-07-07 17:52:38 UTC
Around how much would the size of the tarball increase?
Comment 8 simonbr 2003-07-07 17:53:47 UTC
About how much would the size of the tarball increase?
Comment 9 mmeeks 2003-07-08 09:35:41 UTC
It seems to me that it's particularly pointless including gtk+ [ much
as I love it ], since Gnome ships the 'bug-buddy' tool anyway that
will do the crash dumping for us on all 'interesting' platforms ;-)

IMHO we should bin the large, complex, platform conditionalized
'backtrace' code in osl/unx/signal.c and replace it with a simple
execv of bug-buddy - which forks gdb, and has a suitably pretty,
presumably accessible GUI.

The suggestion of using raw X11, Xt, Xawt is a total joke though -
creating an accessible, internationalizable application with them is
just totally non-feasible. We require blind, arabic speakers to have a
sane experience - surely.
Comment 10 khendricks 2003-07-08 12:29:59 UTC
Hi,  
  
You realize of course that VCL only needs X11, Xt (and not even Xawt anymore)  
under Unix.  
  
It can be and has been done for a long time.  
  
Also, not everyone runs gnome (or even wants to), so your bug buddy idea won't 
float. 
 
Kevin  
  
Comment 11 hennes.rohling 2003-07-08 15:21:57 UTC
Seems as the intention of crashrep is not clear. We don't only want to
create some backtrace info. We want to map the stack to source line
info and for that we need the source base of the build. Furthermore we
want to have an automated process so just attaching a stack to an
issue is not enough because that won't allow to install an automated
process. And we want to get stacks even from those OOo user that don't
know how or don't want to file an issue for convenience reasons.

Anyhow as I proposed at porting.dev we won't include gtk+ neither in
CVS nor do we ibnclude gtk+ libraries in OOo installation sets.

Title changed:

ENABLE_CRASHDUMP=TRUE   

- compiling sources with debug switches (-g, -g0, -Zi)
- build crashrep, linking dynamically against gtk+
- installing crash_report.bin but no gtk+ libraries. gtk libraries
have to be available on target system to make crash_report work.

ENABLE_CRASHDUMP=

- compiling sources without debug switches
- don't build crashrep at all and therefor nothing to install

ENABLE_CRASHDUMP=STATIC (only for StarOffice, no configure switch)

- compiling sources with debug switches (-g, -g0, -Zi)
- build crashrep, linking statically against gtk+
- installing crash_report.bin (including static linked gtk+ code)




Comment 12 pavel 2003-07-08 15:55:17 UTC
So we can get rid of gtk testing when we do not want to build crashrep?
Comment 13 khirano 2003-07-08 15:58:09 UTC
>ENABLE_CRASHDUMP=TRUE

How and where do we set this?
This is not ENABLE_CRASHDUMP="TRUE" ?    

>- compiling sources with debug switches (-g, -g0, -Zi)

Please give us descriptions for -g, -g0 and -Zi

>ENABLE_CRASHDUMP=

How do we set this?

>ENABLE_CRASHDUMP=STATIC (only for StarOffice, no configure switch)

This is nothing for OOo?

Do these work for 1.1rc2 yet?
 




Comment 14 quetschke 2003-07-08 16:22:21 UTC
> ENABLE_CRASHDUMP=STATIC (only for StarOffice, no configure switch)
>
> - compiling sources with debug switches (-g, -g0, -Zi)
> - build crashrep, linking statically against gtk+
> - installing crash_report.bin (including static linked gtk+ code)

Why? The last patch in issue 14472 would also allow
  --enable-crashrep=STATIC
Is this wrong in general, if yes I'll remove that feature?
Comment 15 hennes.rohling 2003-07-08 17:01:51 UTC
@Pavel: Yes
@khirano: see issue 14472, -g, -g0 and -Zi are just the compiler debug
switches for the gcc, Forte 7 and microsoft compilers

@Volker: 
> Why? The last patch in issue 14472 would also allow
>  --enable-crashrep=STATIC

The configure switch is still '--enable-crashdump' or did you change that?

From my point of view we don't need --enable-crashrep=STATIC because I
don't intend to maintain linking crashrep statically against gtk+
anymore. I only want to do this for StarOffice. Otherwise we would
just combine two already existing configure switches but I'm not
getting rid of the problem with static linked gtk. To allow static
linking of gtk we need additonal patches for pkg-config to support the
'--only-modlibs' switch.

I know I'm getting kicked ass for this ;-) but let me give a short
explanation why we are doing so:

SUN is providing the OOo snapshot builds for Linux x86, Solaris Sparc
and Win32. For those builds we'll enable static linking of gtk along
with crashreporter because we can do the static linking without
further patches and we want to make sure to get crash report from all
users not only from those who have a gtk installed.

For all other builds (localizations, other platforms) we are not able
to match the stacks to debug information in source trees because the
source trees are not available (Actually solver is not enough). For
those builds we would just get backtraces with symbols from stripped
libraries which won't be very helpfull.

So for all other builds it's the decision of the porter if he wants to
provide a crashreporter or not. If so there's still the option to link
dynamically against gtk and enable the crashreporter on those runtime
system that have a gtk. Or he can gid rid of the complete feature
along with avoiding to generate disk space consuming debug information.

Please keep in mind that crashreporter can help to increase the
quality of OOo and we need it that way to get a suitable metric and
can provide an automated process.
Comment 16 quetschke 2003-07-08 17:17:42 UTC
@Hennes:
> The configure switch is still '--enable-crashdump' or did you change
> that?
No, it was a typo on my side, but ..

> From my point of view we don't need --enable-crashrep=STATIC because I
> don't intend to maintain linking crashrep statically against gtk+
> anymore.
.. I enhanced --enable-crashdump a bit, in addition to just
--enable-crashdump you can now use --enable-crashdump=<opt> with
<opt> = "yes" or "TRUE" and <opt> = "STATIC". All other parameters
will result in an error.

> I only want to do this for StarOffice. Otherwise we would
> just combine two already existing configure switches but I'm not
> getting rid of the problem with static linked gtk. To allow static
> linking of gtk we need additonal patches for pkg-config to support the
> '--only-modlibs' switch.
Maybe some packages want to do that, I think the
--enable-crashdump=STATIC option doesn't hurt, it just won't work for
the avarage user. (It's also not documented)
Comment 17 khirano 2003-07-09 01:22:32 UTC
Hi,

On SuSE Linux 8.1, kernel2.4.19, gcc3.3, glibc2.2.5, jdk1.4.1 and
gtk+2.0 plus its all related libraries, I finished building 1.1rc
using cws_srx645_ooo11rc2 with c_o3.diff committed by Volker.

Now my "./configure --enable-crashdump" shows (in summary):
-------------------------------------------------------------
checking the operating system... checked (Linux)
checking for gcc... ccache gcc
checking whether ccache gcc accepts -g... yes
checking the GNU gcc compiler version... checked (gcc 3.3)
checking whether ccache g++ accepts -g... yes
checking the installed JDK... checked (JDK 1.4.1_02)
checking the Perl version... checked (perl 5)
checking for pkg-config... /usr/local/bin/pkg-config
checking for gtk+-2.0 >= 1.3.13 ... yes
checking GTK_CFLAGS... -I/usr/local/include/gtk-2.0
-I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0
-I/usr/local/include/pango-1.0 -I/usr/X11R6/include
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
checking GTK_LIBS... -Wl,--export-dynamic -L/usr/local/lib
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
checking for ant... /home/khirano/apache-ant-1.5.3-1/bin/ant
checking if /home/khirano/apache-ant-1.5.3-1/bin/ant works... Ant works

********************************************************************

# Platform independent constant values.

The variable ENABLE_STATIC_GTK is set to: FALSE

# Variable values.

The variable ENABLE_CRASHDUMP  is set to: TRUE
------------------------------------------------


Then I installed this build, making sure that crash_report and
crash_report.bin were in /OpenOffice.org1.1/program/, and run Writer.
Opened my terminal and did:
ps -auwx | grep soffice
kill -s 6 soffice_ps_number

This resulted in just soffice crashing without popping up the
crash_reporter dialogue.

Now what should have done to make the crash_reporter pop up when
soffice crashes?

Is it something like setting env var OOO_RELEASE_BUILD to TRUE, as
Sander suggested in release@ below?:
-----------------------------------------------
On Fri, 27 Jun 2003, Kevin B. Hendricks wrote:
> Hi,
> What about the crashrep issues?  Have any fixes for these been
included in the 
> tree yet?  Is there any "official" word on how we should handle that
issue in 
> "configure"?
my bad - i was going to send out the mail yesterday, but seems it slipped
- so what presently exists (and what I commited yesterday) in scp is being
able to set environment variable OOO_RELEASE_BUILD to TRUE which will then
cause the server to be set. 

Its not in configure - i think we should figure out first what are
"official" builds and who should set it. Just IMHO - its easily changable
if its a bad idea, I don't have a strong opinion about this. 

Sander
--------------

Thanks
khirano






Comment 18 hennes.rohling 2003-07-11 16:24:31 UTC
The crash_reporter only comes up if bootstraprc contains the following
section with ErrorReportServer having a value.

[ErrorReport]
ErrorReportPort=80
ErrorReportServer=report.services.openoffice.org

Thes entries are only written for official release builds.
Comment 19 hennes.rohling 2003-07-11 16:47:28 UTC
Reassigned.
Comment 20 khirano 2003-07-12 13:55:40 UTC
Now I have succeeded to building 1.1rc2 with ErrorReport really enabled.

I set the debug switch "-g1" instead of "-g."

I tried this with two sources:
-- 28eb61c5daeabb2f489f9793a5cbb97d  OOo_1.1rc_source.tar.gz
(hereinafter rc1) and 
-- cws_srx645_ooo11rc2 (hereinafter rc2)

1) rc1 (Building with Vine2.1.5, kernel2.4.21, glibc2.1.3, gcc3.3,
jdk1.4.1, gtk+2 etc.) 

- No using --enable-crashdump:
  ENABLE_CRASHDUMP="" in LinuxIntelEnv.Set.sh

- Add "-g1" to /solenv/inc/unxlngi4.mk:
  # flags for C and C++ Compiler
  CFLAGS+=-fmessage-length=0 -c $(INCLUDE) -g1  <<--- Add "-g1"
  # flags required for crashdump feature
  CFLAGSCRASHDUMP=-g

- Installing rc1 creates bootstraprc:
  [Bootstrap]
  ProductKey=OpenOffice.org 1.1
  Location=$SYSUSERCONFIG/.sversionrc
  Section=Versions
  BaseInstallation=$ORIGIN/..
  UserInstallation=$ORIGIN/..
  buildid=645(Build:8639)
  InstallMode=STANDALONE
  ProductPatch=

  [ErrorReport]
  ErrorReportPort=80
  ErrorReportServer=

- Enter a server name for ErrorReportServer:
  ErrorReportServer=report.services.openoffice.org

- On SuSE8.1:
  ErrorReport doesn't come up when soffice crashes.

- On RedHat8:
  ErrorReport doens't come up when soffice crashes.

2) rc2 (Building with Suse8.1, kernel2.4.19, glibc2.2.5, gcc3.3,
jdk1.4.1, gtk+2 etc.) 

- Use --enable-crashdump:
  ENABLE_CRASHDUMP="TRUE" in LinuxIntelEnv.Set.sh

- Add "-g1" to /solenv/inc/unxlngi4.mk:
  # flags for C and C++ Compiler
  CFLAGS+=-fmessage-length=0 -c $(INCLUDE)
  # flags required for crashdump feature
  CFLAGSCRASHDUMP=-g1                       <<-- Use "-g1" instead of "-g"

- Installing rc2 creates bootstraprc:
  [Bootstrap]
  ProductKey=OpenOffice.org 1.1
  Location=$SYSUSERCONFIG/.sversionrc
  Section=Versions
  BaseInstallation=$ORIGIN/..
  UserInstallation=$ORIGIN/..
  buildid=645(Build:8651)
  InstallMode=STANDALONE
  ProductPatch=

  [ErrorReport]
  ErrorReportPort=80
  ErrorReportServer=

- Enter a server name for ErrorReportServer:
  ErrorReportServer=report.services.openoffice.org

- On SuSE8.1:
  ErrorReport comes up when soffice crashes and looks fine.

- On RedHat8:
  ErrorReport comes up when soffice crashes and looks beautiful.
http://www.transwift.net/ooo/11rc_ErrorReport.html

Thanks
khirano
Comment 21 philipp.lohmann 2003-07-14 11:24:17 UTC
what a mess ...
Comment 22 philipp.lohmann 2003-07-14 14:54:00 UTC
fixed in CWS setupicon
Comment 23 philipp.lohmann 2003-07-14 16:19:24 UTC
fixed in CWS setupicon
Comment 24 uwe.luebbers 2003-07-15 10:09:02 UTC
Hi all,

Sorry, was a little misunderstanding. I think this is a developer 
task and PL agreed. I'll test the little rest (crashreporter still 
working eg.).
Comment 25 Olaf Felka 2003-07-15 10:18:52 UTC
Reassigning
Comment 26 philipp.lohmann 2003-07-15 10:28:12 UTC
.
Comment 27 philipp.lohmann 2003-07-15 10:28:45 UTC
verified in CWS setupicon
Comment 28 philipp.lohmann 2003-07-17 09:43:24 UTC
merged in m13s1, closing
Comment 29 thammotorle 2010-11-10 17:10:11 UTC
Created attachment 73404