headers
Peter Weilbacher | 7 Oct 2007 23:55

The kLibc EAs

I'm getting more and more complaints about the EAs that gcc335-compiled 
version of the Mozilla apps create. I can tell ZIP to not package any 
EAs (-X), so the package is free of them. But at least some files 
created by the programs still get EAs attached to them. Is there a way 
to suppress that? Some linker option or #define maybe?

The most recent complain is that these EAs are marked critical even 
though they are not critical at all for using SeaMonkey or Firefox...
--

-- 
Greetings,  | My From: address is valid as is the version without "spam"
   Peter.   |     I try to find real messages among the spam once a week
Permalink | Reply | 2 comments |
headers
Knut St. Osmundsen | 8 Oct 2007 14:03
Favicon

Re: The kLibc EAs

Peter Weilbacher wrote:
> I'm getting more and more complaints about the EAs that gcc335-compiled 
> version of the Mozilla apps create. I can tell ZIP to not package any 
> EAs (-X), so the package is free of them. But at least some files 
> created by the programs still get EAs attached to them. Is there a way 
> to suppress that? Some linker option or #define maybe?
> 
> The most recent complain is that these EAs are marked critical even 
> though they are not critical at all for using SeaMonkey or Firefox...

Perhaps not, but they are critical for using kLIBC... I don't quite 
recall whether there is an easy way of disabling them, and since I don't 
have the source handy it's a bit difficult to find out.

Kind Regards,
  knut
Permalink | Reply | 1 comment |
headers
kLIBC | 9 Oct 2007 22:15
Picon

[kLIBC] #187: strftime is broken for several locales

#187: strftime is broken for several locales
--------------------+-------------------------------------------------------
 Reporter:  guest   |       Owner:  bird 
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  libc    |     Version:  0.6.2
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 This is basically what I found out in
 https://bugzilla.mozilla.org/show_bug.cgi?id=396798


 strftime gives wrong results for several locales, including en_GB (wrong
 minutes) and pl_PL (wrong day and month names), and several other eastern
 European locales (month name replaced with X).

 I tested with GCC 3.2.2 and 3.3.5 and both give the same problems.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/187>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 1 comment |
headers
kLIBC | 9 Oct 2007 22:23
Picon

Re: [kLIBC] #187: strftime is broken for several locales

#187: strftime is broken for several locales
--------------------+-------------------------------------------------------
 Reporter:  guest   |        Owner:  bird 
     Type:  defect  |       Status:  new  
 Priority:  normal  |    Milestone:       
Component:  libc    |      Version:  0.6.2
 Severity:  normal  |   Resolution:       
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by guest):

 * cc: mozilla <at> weilbacher.org (added)

Comment:

 Output of the test program:

 tryLocale=en_US: buf=Wed Oct 17 20:59:00 CEST 2007 (result=29)
 tryLocale=de_DE: buf=Mi 17 Okt 20:59:00 2007 (result=23)
 tryLocale=en_GB: buf=Wed 17 Oct 20:20:00 CEST 2007 (result=29)
 tryLocale=pl_PL: buf=r. 17 X 2007 20:59:00 (result=22)
 tryLocale=cz_CZ: buf=r. 17 X 2007 20:59:00 (result=22)
 tryLocale=sk_SK: buf=st 17 X 2007 20:59:00 (result=21)
 tryLocale=fi_FI: buf=ke 17 loka 20.59.00 2007 (result=24)
 tryLocale=hu_HU: buf=Sze 17 okt. 2007 20:59:00 (result=25)
 tryLocale=es_ES: buf=mié oct 17 20:59:00 CEST 2007 (result=29)

 For en_GB it should be
    Wed 17 Oct 20:59:00 CEST 2007 [with 59 instead of 20]
 instead, for pl_PL
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Ratcliffe | 12 Oct 2007 02:13
Picon

GCC param.h

Hope this is the right place for this...

In GCC 3.3.5-CSD3 in file usr\include\sys\param.h it says:

#if defined (__cplusplus) && (__GNUC__ >= 2)
#  define MIN(a,b) (((a)<?(b))
#else
#  define MIN(a,b) (((a)<(b))?(a):(b))
#endif
#if defined (__cplusplus) && (__GNUC__ >= 2)
#  define MAX(a,b) (((a)>?(b))
#else
#  define MAX(a,b) (((a)>(b))?(a):(b))
#endif

There is an extra bracket on the first form of MIN and MAX (count 'em!).
It should read:
#  define MIN(a,b) ((a)<?(b))
and
#  define MAX(a,b) ((a)>?(b))

I can't imagine that this has ever worked or how it has been missed for so
long.
Permalink | Reply | 0 comments |
headers
Peter Weilbacher | 13 Oct 2007 18:34

Re: The kLibc EAs

On 08.10.07 14:03, Knut St. Osmundsen wrote:

> Perhaps not, but they are critical for using kLIBC... I don't quite 
> recall whether there is an easy way of disabling them, and since I don't 
> have the source handy it's a bit difficult to find out.

How about a link to somewhere below 
<http://svn.netlabs.org/libc/browser/branches/libc-0.6>? I can't find it 
myself in there but a pointer might help...
Btw, don't know what you mean by "critical for kLIBC". I can remove all 
those EAs from all files without any bad effects. Just that they come 
back all the time.
    Peter.
Permalink | Reply | 0 comments |
headers
Peter Weilbacher | 24 Oct 2007 21:56

emxomfar error: "Source library too big"

I already posted this to the Mozilla newsgroup but that didn't help to 
resolve the problem, seems like I'm the only one with this experience...

My most recent attempts to build Firefox result in weird failures like 
this:

   rm -f docshell.lib
   emxomfar r docshell.lib nsDocShellModule.o 
      ../base/basedocshell_s.lib
      ../../uriloader/base/uriloaderbase_s.lib 
      ../../uriloader/exthandler/exthandler_s.lib 
      ../../uriloader/prefetch/prefetch_s.lib
      ../shistory/src/shistory_s.lib
   emxomfar: docshell.lib(../../uriloader/exthandler/exthandler_s.lib): 
      Source library too big
   Creating library file `docshell.lib'
   make.exe[4]: *** [docshell.lib] Error 2
   make.exe[4]: Leaving directory `M:/trunk/obj-fx/docshell/build'

But that must be rubbish. The same stuff works fine in layout/build with
.lib files that are a factor of 10 larger?!

So, what else can this error message mean?
--

-- 
Greetings,  | My From: address is valid as is the version without "spam"
   Peter.   |     I try to find real messages among the spam once a week
Permalink | Reply | 7 comments |
headers
Yuri Dario | 27 Oct 2007 22:32
Picon
Favicon

Re: emxomfar error: "Source library too big"

Hi Peter,

>    emxomfar r docshell.lib nsDocShellModule.o 
> So, what else can this error message mean?

try adding -p xxx parameter, I need it for big libraries (e.g. -p 128)

Yuri
Permalink | Reply | 6 comments |

Gmane