idem for 644_m4

Reassigning based on similar issues 3723 and 4153, which were both
looked at by Christof.

Confirming this issue.  I cannot run 644_m4, or my own build, on
Debian Woody (libc 2.2.5) or unstable (libc 2.3.1).

This may be the same as issue 11695, but the error messages are so
different I am not marking as duplicate at the moment.  Issue 11695
was marked as duplicate of issue 10210, but I am not sure of this - I
do not see the reported unresolved symbol errors.

I also discussed the problem on releases@ - here is the link:
http://www.openoffice.org/servlets/ReadMsg?msgId=590997&listName=releases

I tested this under KDE 3.1 and plain twm window managers, by the way.

cp->pl: please have a look and/or follow up with Chris.

This is the same as 12607, i'll close that one as duplicate. I'll also
copy our findings from OOo con here:

in sal/osl/unx/socket.c:870 in case of a missing /bin/domainname there
is an exit(-1) in the fork'ed process. This is not really wrong, but
causes bad side effects: destructors are called which e.g. close the X
display connection; since the connection is shared after the fork() it
tells the Xserver that this client is dead, which leads to the main
process receiving an XIO error (or IceIO error whichever comes first)
- meaning instant termination of the main process. Please use _exit()
instead which will not cose such problems as it only close the open
file descriptors for the fork()'ed process. Please also have a look
whether there are similar action in the code.

Please fix this for OOo 1.0.3 also.

*** Issue 12607 has been marked as a duplicate of this issue. ***

*** Issue 12751 has been marked as a duplicate of this issue. ***

I am seeing a similar issue on debian, but I am not seeing any error
messages. The soffice process is running, but no windows appear (I can
see the soffice.bin in the process table). The problem occurs on
644_m4 and 1.1beta (643c does not have this problem). Is this caused
by the same issue?

haggai->in1t: You can work around the bug described here by exporting
STAR_OVERRIDE_DOMAINNAME=<your domain name>

for example, you could try:

killall -9 soffice.bin
STAR_OVERRIDE_DOMAINNAME=mydomain.com ./soffice

(Execute the killall first to make sure that you don't have any hung
processes around)

that helped me. thanks

*** Issue 12695 has been marked as a duplicate of this issue. ***

JA: verified fix in cws_sal01. Application starts if /bin/domainname
cannot be accessed by user process on Debian Woody.

*** Issue 13058 has been marked as a duplicate of this issue. ***

Hi Chris, 
 
Since I have to rebuild OOo 1.0.3 and OOo 1.1 on PPC Linux to make a release, I would 
really like to incorporate a fix for this in my release builds. 
 
Jack Howarth of Debian was helpng me test my latest 1.1 Beta build and he ran into 
exactly this problem. 
 
Can you point me to which files I need to update or a patch that will fix this problem for 
Debian users so that I can incorporate it into my OOo 1.1 Beta build so that it will actually 
startup properly. 
 
Thanks, 
 
Kevin 
 

Hi Kevin, just pick up the last change to sal/osl/unx/socket.c, as the
comment before said.  Revision 1.17.48.1 has the change.

===================================================================
RCS file: /cvs/porting/sal/osl/unx/socket.c,v
retrieving revision 1.17.48.1
retrieving revision 1.17
diff -u -3 -p -r1.17.48.1 -r1.17
--- socket.c    1 Apr 2003 12:52:08 -0000       1.17.48.1
+++ socket.c    9 Apr 2002 18:09:53 -0000       1.17
@@ -867,7 +867,7 @@ static sal_Bool  _osl_getDomainName (sal

                        if (execvp ("/bin/domainname", argv) < 0)
                        {
-                               _exit(-1);
+                               exit(-1);
                        }
                }
                else if (pid > 0)

Chris

*** Issue 13401 has been marked as a duplicate of this issue. ***

Verified in OOo1.1 Beta2.

*** Issue 13003 has been marked as a duplicate of this issue. ***

*** Issue 14562 has been marked as a duplicate of this issue. ***

FWIW, the earlier betas and rc's didn't work for me on Woody,
but ooo1.1.0rc4 works fine.  No idea why.  I'm just glad it's working.

Hi

I'm building localized OO (r2, rc3, rc4).
During general (setup -net) and user install i get no warnings,
no errors.

OpenOffice always dies with:
 "OpenOffice.org 1.1 cannot be started due to an error in accessing 
the configuration data. Please contact your system administrator. 
Internal error: Get storage, name "No content" "

Corresponding changes to sal/osl/unx/socket.c doesn't help.

In the ~/OpenOffice.org1.1/setup.log i found next error (duplicated):
..
OK  configuration: write Key 'ooLocale' in 'org.openoffice.Setup/L10N
..
The backend returned the following error:
Configuration Parser: a com.sun.star.uno.Exception occurred while 
parsing: LayerParser - Ending ElementSTRING has no boolean value!- 
{Parser Error: [ line 25]: Noerror }.
ERR /org.openoffice.Office.Common (and for locale *) could not be 
created. Unable to retrieve the node from the configuration server.

Also i have found several empty files (like Chart.properties, Common.
properties, UI.properties, ..) in 
share/registry/res/uk/org/openoffice/Office/ .

Sorry people.

I accidently translate string "true" (extracted by localize) in
/officecfg/registry/data/org/openoffice/Office/Common.xcu

Other problem was incorrect value for KEY_ALL_LANG in /scp/inc/gcfg.
inc

> STAR_OVERRIDE_DOMAINNAME=mydomain.com ./soffice

Can please someone explain this setting (what is the domain used for;
is the second value the settings directory, and shouldn't it be
~/soffice in a Linux context)? Will this help be with my crashing OOo
1.1.0 on Windows XP

haggai->Number5:
> Can please someone explain this setting (what is the domain used for

It was a bug in a lowlevel routine that was used in several places
when the machine's domain name was needed.

> is the second value the settings directory, and shouldn't it
be~/soffice in a Linux context)?

No, the space marks the end of the value to be assigned to the
variable.  ./soffice is the path and name of the binary to start.

> Will this help be with my crashing OOo1.1.0 on Windows XP
No, this was Unix-specific (note the 'unx' in the patched filename). 
And it was closed well before 1.1.0.  The 'Target Milestone' field of
resolved bugs shows you which version contained the fix, which was 1.1
Beta2 in this case.

*** Issue 12695 has been marked as a duplicate of this issue. ***