Build path strings inside my binary libraries

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Build path strings inside my binary libraries

An Bo
Hello, I have built some libraries with MinGW/MSYS and I noticed that the build path is saved in them, in the form:

C:\MinGW\msys\1.0\home\UserName\LibraryDir

How can I prevent that information from being saved to the binaries?
.A, .DLL and .EXE files are all affected by this, with the build path appearing multiple times in each file.

This isn't so much a privacy issue as it is a practical one: useless stuff that my users don't need ought to be stripped. I'm curious to know why this happens in the first place. Am I forgetting to pass a flag to the configure script? Thanks.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Eli Zaretskii
> From: "An Bo" <[hidden email]>
> Date: Fri, 1 May 2015 10:44:25 +0200
>
> Hello, I have built some libraries with MinGW/MSYS and I noticed that the build path is saved in them, in the form:
>
> C:\MinGW\msys\1.0\home\UserName\LibraryDir
>
> How can I prevent that information from being saved to the binaries?

That depends on what is in the sources, I guess.  Please show the
source of the smallest .exe program that exhibits this issue.

One thing you need to remember is that the debug info produced by the
compiler includes the compilation directory (so that a debugger could
find the sources), so you should strip the binary files to remove that
info.

> .A, .DLL and .EXE files are all affected by this, with the build path appearing multiple times in each file.

Strip them, and then try again.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

An Bo
In reply to this post by An Bo

>That depends on what is in the sources, I guess.  Please show the
>source of the smallest .exe program that exhibits this issue.

They all do, so I think posting the source code would be pointless. Two of the libraries I built are libjpeg v.9a and libpng 1.6.17, but they are all affected.

>One thing you need to remember is that the debug info produced by the
>compiler includes the compilation directory (so that a debugger could
>find the sources), so you should strip the binary files to remove that
>info.

I have tried stripping but it doesn't seem to work.
Please tell me how to do it correctly, because I have tried:
 
sh ./configure LDFLAGS="-s"
make

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Keith Marshall
On 01/05/15 11:02, An Bo wrote:
>> That depends on what is in the sources, I guess.  Please show the
>> source of the smallest .exe program that exhibits this issue.
>
> They all do, so I think posting the source code would be pointless.
> Two of the libraries I built are libjpeg v.9a and libpng 1.6.17, but
> they are all affected.

Eli means "please show us a *minimal* source code example which exhibits
the problem"; he does not mean post all of your sources.

>> One thing you need to remember is that the debug info produced by
>> the compiler includes the compilation directory (so that a debugger
>> could find the sources), so you should strip the binary files to
>> remove that info.
>
> I have tried stripping but it doesn't seem to work. Please tell me
> how to do it correctly, because I have tried:
>
> sh ./configure LDFLAGS="-s" make

That assumes that the project's makefile actually honours the LDFLAGS
setting specified at configure time.  Once again, that isn't what I take
Eli to mean; he more likely means strip the executables *after* you have
built them:

  strip foo.exe

is the preferred way to remove debugging information, inserted by the
CFLAGS='-g -O2' *compile* time flags, which are common in GNU style builds.

BTW, if you follow this build paradigm, you can avoid the complexity of
discriminating between release and debug builds at build time; just
build *everything* as a debug build, then strip (a copy of) the result,
after the event, to produce a release.

--
Regards,
Keith.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

An Bo
In reply to this post by An Bo
>That assumes that the project's makefile actually honours the LDFLAGS
>setting specified at configure time.  Once again, that isn't what I take
>Eli to mean; he more likely means strip the executables *after* you have
>built them:
>
>  strip foo.exe

Thank you, the strip utility was what I was looking for:
  strip -g *

Running the above solved my issue. (Running without the "-g" flag made the libraries unlinkable.)

>is the preferred way to remove debugging information, inserted by the
>CFLAGS='-g -O2' *compile* time flags, which are common in GNU style builds.

This is a detour from the original subject of this email but I would like to know, for Win32 development, is it good practice to use:

  CFLAGS="-march=i686 -mtune=i686 -O3"

instead of allowing the defaults, which may tune for Pentium or maybe current CPU?

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Eli Zaretskii
> From: "An Bo" <[hidden email]>
> Date: Fri, 1 May 2015 14:06:26 +0200
>
> >That assumes that the project's makefile actually honours the LDFLAGS
> >setting specified at configure time.  Once again, that isn't what I take
> >Eli to mean; he more likely means strip the executables *after* you have
> >built them:
> >
> >  strip foo.exe
>
> Thank you, the strip utility was what I was looking for:
>   strip -g *
>
> Running the above solved my issue. (Running without the "-g" flag made the libraries unlinkable.)

Keith specifically talked about *.exe files, for them you don't need
the -g switch.

For libraries, the procedure differs depending on whether the library
is a static *.a one or a shared *.dll:

   strip --strip-unneeded *.dll
   strip -g *.a

You should also run "ranlib" on each *.a file after stripping them.

> This is a detour from the original subject of this email but I would like to know, for Win32 development, is it good practice to use:
>
>   CFLAGS="-march=i686 -mtune=i686 -O3"
>
> instead of allowing the defaults, which may tune for Pentium or maybe current CPU?

I don't recommend -O3, it usually bloats the program size without any
perceptible improvement in performance.  Only use -O3 when the project
defaults to that, since some rare code really needs that.

I generally find "-O2 -gdwarf-4 -g3" the best configuration; if you
don't care about debugging, just -O2 is the best.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Eli Zaretskii
In reply to this post by An Bo
> From: "An Bo" <[hidden email]>
> Date: Fri, 1 May 2015 12:02:42 +0200
>
> >One thing you need to remember is that the debug info produced by the
> >compiler includes the compilation directory (so that a debugger could
> >find the sources), so you should strip the binary files to remove that
> >info.
>
> I have tried stripping but it doesn't seem to work.
> Please tell me how to do it correctly, because I have tried:
>  
> sh ./configure LDFLAGS="-s"
> make

No, that's not how most packages support stripping.  You strip the
binaries when you install them, like this:

  make install-strip

IOW, use the 'install-strip' target, which will invoke 'strip' with
correct switches.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

An Bo
In reply to this post by An Bo
>No, that's not how most packages support stripping.  You strip the
>binaries when you install them, like this:
>
>  make install-strip
>
>IOW, use the 'install-strip' target, which will invoke 'strip' with
>correct switches.

Thanks, I didn't know that.
Since you mentioned ranlib, will install-strip run ranlib automatically?

Also should switches be used with ranlib? Or is it enough to simply call it without switches?

>I don't recommend -O3, it usually bloats the program size without any
>perceptible improvement in performance.  Only use -O3 when the project
>defaults to that, since some rare code really needs that.

Understood. What do you think about "-O2 -march=i686 -mtune=generic" instead?

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Eli Zaretskii
> From: "An Bo" <[hidden email]>
> Date: Fri, 1 May 2015 15:20:25 +0200
>
> >No, that's not how most packages support stripping.  You strip the
> >binaries when you install them, like this:
> >
> >  make install-strip
> >
> >IOW, use the 'install-strip' target, which will invoke 'strip' with
> >correct switches.
>
> Thanks, I didn't know that.
> Since you mentioned ranlib, will install-strip run ranlib automatically?

Yes.

> Also should switches be used with ranlib? Or is it enough to simply call it without switches?

Without switches.

> >I don't recommend -O3, it usually bloats the program size without any
> >perceptible improvement in performance.  Only use -O3 when the project
> >defaults to that, since some rare code really needs that.
>
> Understood. What do you think about "-O2 -march=i686 -mtune=generic" instead?

Can't hurt, I think.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Keith Marshall
On 01/05/15 15:56, Eli Zaretskii wrote:
>>> I don't recommend -O3, it usually bloats the program size without any
>>> perceptible improvement in performance.  Only use -O3 when the project
>>> defaults to that, since some rare code really needs that.
>>
>> Understood. What do you think about "-O2 -march=i686 -mtune=generic" instead?
>
> Can't hurt, I think.

That depends on your intended audience.  One of the criticisms of our
(Earnie's) GCC-4.8.1 build was that it would generate code which could
not be run on older hardware.  If you value supporting users who still
run older hardware, maybe don't set -march so restrictively.

FWIW, I built GCC-4.8.2 with "-march=i586 -mtune=generic", to ensure
default code generation for any vintage of Pentium class CPU.  You may
choose a more recent CPU class, but the price is reduced accessibility
to your application, for users of older hardware.

--
Regards,
Keith.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

Eli Zaretskii
> Date: Sat, 02 May 2015 04:09:27 +0100
> From: Keith Marshall <[hidden email]>
>
> On 01/05/15 15:56, Eli Zaretskii wrote:
> >>> I don't recommend -O3, it usually bloats the program size without any
> >>> perceptible improvement in performance.  Only use -O3 when the project
> >>> defaults to that, since some rare code really needs that.
> >>
> >> Understood. What do you think about "-O2 -march=i686 -mtune=generic" instead?
> >
> > Can't hurt, I think.
>
> That depends on your intended audience.

Yes, I agree.  My response implicitly assumed that the OP builds the
programs for their own consumption.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Build path strings inside my binary libraries

An Bo
In reply to this post by Keith Marshall
> Sent: Saturday, May 02, 2015 at 5:09 AM
> From: "Keith Marshall" <[hidden email]>
> To: "Eli Zaretskii" <[hidden email]>, "MinGW Users List" <[hidden email]>
> Subject: Re: [Mingw-users] Build path strings inside my binary libraries
>
> That depends on your intended audience.  One of the criticisms of our
> (Earnie's) GCC-4.8.1 build was that it would generate code which could
> not be run on older hardware.  If you value supporting users who still
> run older hardware, maybe don't set -march so restrictively.
>
> FWIW, I built GCC-4.8.2 with "-march=i586 -mtune=generic", to ensure
> default code generation for any vintage of Pentium class CPU.  You may
> choose a more recent CPU class, but the price is reduced accessibility
> to your application, for users of older hardware.
>

In my case, the application is a computer game. As a result I'm concerned
that I don't set -march high enough! I fully agree that when building utilities
and command line tools, -march should be set low. (FreeDOS comes to mind.)

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe