public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: The Quest for lean binaries...
@ 1997-03-17 23:37 Larry Hall
  0 siblings, 0 replies; 3+ messages in thread
From: Larry Hall @ 1997-03-17 23:37 UTC (permalink / raw)
  To: bela, gnu-win32

Hi Bernd,

I don't really have a good explanation for you of the current state (although
I'm sure someone on this list will!) but I can tell you what I've heard and
how you SHOULD be able to get smaller executables on NT.  Stripping
executables apparently strips too much, making the executable useless.  I'm
not sure why things would still be OK under 95 in this case.  Perhaps 95 is
too stupid to know it shouldn't like the executable!;-)  Anyway, from what
I've heard, you should be able to get a smaller executable by compiling a
non-debug version (rather than a debug version and then stripping it).  I
am, of course, assuming you are building a debug version and then stripping
it (which is essentially what happens behind the scenes with -s option).  I
have not myself heard of a resolution to the stripping problem though....

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (617) 239-1053
8 Grove Street                          (617) 239-1655 - FAX
Wellesley, MA  02181                             


At 05:13 PM 3/17/97 +1, BERND LASER wrote:
>Ladies and Gentlemen,
>
>again and again and again ...
>we have to deal with the infamous 'not owner' problem which turns out 
>to be corrupted executables at least under NT4. After reading FAQs 
>and searching ml-archives this doesn't seem to me to be really straightened 
>out at all.
>I have successfully compiled a quite large seismic processing package 
>in plain 'C' under cygwin32 which consits of quite a few but mostly 
>quite small modules. Using gcc's -s options i get corrupted exe's not 
>running under NT. Avoiding it they run but are too large (for my 
>humble opinion).
>The other day then I loaded some exe's for cygwin32 down ('man' in 
>particular), found them quite lean and - Not owner! Got suspicious 
>then, tested them under win95, and they seem to run OK.
>
>So, is this just the status quo? Or is there any solution to get lean 
>exe's also under, say, NT4SP2 ? I don't think copying the libc++ from 
>Beta 14 would help me anyhow.
>
>I would really appreciate any kind of answer !
>
>Regards.
>____________________________________________________________________________
>Bernd Laser
>Dep. of Earth Sciences
>University of Bremen
>
>FON:               FAX:               EMail:
>+49 421 218 7286   +49 421 218 7179   bela@mtu.uni-bremen.de
>
>Snail:
>   Bernd Laser
>   Universitaet Bremen, FB 5
>   P.O. Box 330440
>   28334 Bremen
>   Germany
>____________________________________________________________________________
>-
>For help on using this list, send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>
>

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: The Quest for lean binaries...
@ 1997-03-18  1:11 Sergey Okhapkin
  0 siblings, 0 replies; 3+ messages in thread
From: Sergey Okhapkin @ 1997-03-18  1:11 UTC (permalink / raw)
  To: gnu-win32, 'bela@mtu.uni-bremen.de'

BERND LASER wrote:
> quite small modules. Using gcc's -s options i get corrupted exe's not 
> running under NT.

It's a cygnus/ld well known bug...

> Avoiding it they run but are too large (for my 
> humble opinion).

Just strip file after linking:

strip <filename.exe>

-- 
Sergey Okhapkin
Moscow, Russia
Looking for a job.


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 3+ messages in thread

* The Quest for lean binaries...
@ 1997-03-17  9:29 BERND LASER
  0 siblings, 0 replies; 3+ messages in thread
From: BERND LASER @ 1997-03-17  9:29 UTC (permalink / raw)
  To: gnu-win32

Ladies and Gentlemen,

again and again and again ...
we have to deal with the infamous 'not owner' problem which turns out 
to be corrupted executables at least under NT4. After reading FAQs 
and searching ml-archives this doesn't seem to me to be really straightened 
out at all.
I have successfully compiled a quite large seismic processing package 
in plain 'C' under cygwin32 which consits of quite a few but mostly 
quite small modules. Using gcc's -s options i get corrupted exe's not 
running under NT. Avoiding it they run but are too large (for my 
humble opinion).
The other day then I loaded some exe's for cygwin32 down ('man' in 
particular), found them quite lean and - Not owner! Got suspicious 
then, tested them under win95, and they seem to run OK.

So, is this just the status quo? Or is there any solution to get lean 
exe's also under, say, NT4SP2 ? I don't think copying the libc++ from 
Beta 14 would help me anyhow.

I would really appreciate any kind of answer !

Regards.
____________________________________________________________________________
Bernd Laser
Dep. of Earth Sciences
University of Bremen

FON:               FAX:               EMail:
+49 421 218 7286   +49 421 218 7179   bela@mtu.uni-bremen.de

Snail:
   Bernd Laser
   Universitaet Bremen, FB 5
   P.O. Box 330440
   28334 Bremen
   Germany
____________________________________________________________________________
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1997-03-18  1:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-03-17 23:37 The Quest for lean binaries Larry Hall
  -- strict thread matches above, loose matches on Subject: below --
1997-03-18  1:11 Sergey Okhapkin
1997-03-17  9:29 BERND LASER

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).