Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #104746 > unrolled thread

How to produce standalone executable using Code::Blocks/Clang ?

Back to article view | Back to comp.lang.c

Contents

  How to produce standalone executable using Code::Blocks/Clang ? MehdiAmini <atorrses@gmail.com> - 2017-02-26 12:01 +0330
    Re: How to produce standalone executable using Code::Blocks/Clang ? fir <profesor.fir@gmail.com> - 2017-02-26 01:55 -0800
      Re: How to produce standalone executable using Code::Blocks/Clang ? fir <profesor.fir@gmail.com> - 2017-02-26 03:35 -0800
    Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-26 14:40 +0100
      Re: How to produce standalone executable using Code::Blocks/Clang ? BartC <bc@freeuk.com> - 2017-02-26 14:13 +0000
        Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-26 17:26 +0100
          Re: How to produce standalone executable using Code::Blocks/Clang ? BartC <bc@freeuk.com> - 2017-02-26 16:56 +0000
            Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-26 19:00 +0100
              Re: How to produce standalone executable using Code::Blocks/Clang ? scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 15:16 +0000
          Re: How to produce standalone executable using Code::Blocks/Clang ? scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 15:12 +0000
            Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-27 16:43 +0100
      Re: How to produce standalone executable using Code::Blocks/Clang ? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 01:12 +0100
        Re: How to produce standalone executable using Code::Blocks/Clang ? BartC <bc@freeuk.com> - 2017-02-27 01:04 +0000
          Re: How to produce standalone executable using Code::Blocks/Clang ? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 06:05 +0100
            Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-27 10:27 +0100
              Re: How to produce standalone executable using Code::Blocks/Clang ? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 12:21 +0100
                Re: How to produce standalone executable using Code::Blocks/Clang ? BartC <bc@freeuk.com> - 2017-02-27 12:14 +0000
                  Re: How to produce standalone executable using Code::Blocks/Clang ? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 14:27 +0100
                Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-27 13:55 +0100
        Re: How to produce standalone executable using Code::Blocks/Clang ? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 08:26 +0000
          Re: How to produce standalone executable using Code::Blocks/Clang ? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 12:25 +0100
            Re: How to produce standalone executable using Code::Blocks/Clang ? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 15:24 +0000
        Re: How to produce standalone executable using Code::Blocks/Clang ? David Brown <david.brown@hesbynett.no> - 2017-02-27 10:22 +0100
        Re: How to produce standalone executable using Code::Blocks/Clang ? scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 15:20 +0000
          Re: How to produce standalone executable using Code::Blocks/Clang ? fir <profesor.fir@gmail.com> - 2017-02-27 07:45 -0800
            Re: How to produce standalone executable using Code::Blocks/Clang ? fir <profesor.fir@gmail.com> - 2017-02-27 08:12 -0800
      Re: How to produce standalone executable using Code::Blocks/Clang ? MehdiAmini <atorrses@gmail.com> - 2017-02-27 10:54 +0330

Page 2 of 2 — ← Prev page 1 [2]

#104840

On Mon, 27 Feb 2017 08:26:29 -0000 (UTC)
Ike Naar <ike@iceland.freeshell.org> wrote:

> It's not so ridiculous. Most of a processor's time is wasted doing nothing.

The most important thing is to not waste the processor's time when the user
need to save his.

[toc] | [prev] | [next] | [standalone]

#104871

On 2017-02-27, GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> On Mon, 27 Feb 2017 08:26:29 -0000 (UTC)
> Ike Naar <ike@iceland.freeshell.org> wrote:
>
>> It's not so ridiculous. Most of a processor's time is wasted doing nothing.
>
> The most important thing is to not waste the processor's time when the user
> need to save his.

From the user's perspective, wasted real (wallclock) time matters
more than wasted CPU time.

If many processes have private copies of runtime libraries instead
of sharing them, RAM may become a scarce resource, and time gets
wasted on handling page faults, or, worse, swapping.

From the user's perspective, if the CPUs are very busy, their
process may run at a lower speed, but it still runs; where as the
system runs out of memory, everything seems to come to a grinding
halt.

In my experience, in multi-user systems, RAM capacity is more likely
to become a bottleneck than CPU capacity is.

[toc] | [prev] | [next] | [standalone]

#104829

On 27/02/17 01:12, GOTHIER Nathan wrote:
> On Sun, 26 Feb 2017 14:40:17 +0100
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> The "-static" flag for gcc asks it to use static linking rather than 
>> using dynamic .so libraries.  You have to have the right static 
>> libraries available, of course.  Static linking can result in 
>> executables that are marginally faster, and they become independent of 
>> the .so files - but they are /much/ bigger.  (On my system, a "Hello 
>> world" with dynamic linking is about 8.6K, with static linking it is 900K.)
> 
> Maybe 900 kilo-octets is sensibly bigger than 8,6 kilo-octets but it is
> ridiculous to save 891,4 kilo-octets with common storage medias over
> 1 Tera-octets while wasting processor's time in loading libraries.
> 

The key libraries involved are already loaded - everything and its dog
links to libc.so and similar fundamental libraries.

How does the extra time needed to load and link 900K compare to the
extra time needed to sort out the dynamical linking?  I don't know - I
doubt if it is much, but I expect the static linked version to start a
touch faster if it is already in ram cache.

For a single "Hello World" program, 900 KB may not seem significant.
But if static linking were the norm, things would be different.  I have
about 400 processes in action at the moment - every one of these would
need its own copy of those 900 KB if they did not use shared libraries
for libc.  That would be 360 MB wasted for nothing.  But if you also
included other dynamic libraries as static, then every program with a
gui or some connection to X (or Windows gui - the same applies there)
would be needing dozens of MB of extra memory (as well as disk space).
I've only got 32 GB of ram on my home machine - it would run out in no time.

[toc] | [prev] | [next] | [standalone]

#104868

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Sun, 26 Feb 2017 14:40:17 +0100
>David Brown <david.brown@hesbynett.no> wrote:
>
>> The "-static" flag for gcc asks it to use static linking rather than 
>> using dynamic .so libraries.  You have to have the right static 
>> libraries available, of course.  Static linking can result in 
>> executables that are marginally faster, and they become independent of 
>> the .so files - but they are /much/ bigger.  (On my system, a "Hello 
>> world" with dynamic linking is about 8.6K, with static linking it is 900K.)
>
>Maybe 900 kilo-octets is sensibly bigger than 8,6 kilo-octets but it is
>ridiculous to save 891,4 kilo-octets with common storage medias over
>1 Tera-octets while wasting processor's time in loading libraries.

The key advantage of shared objects are that the text page(s) for the
shared object can be shared between all processes/threads on the system
reducing the physical memory footprint of all processes.  Consider libc,
which is shared by pretty much every process on the system - if each had
their own subset because they were statically linked, the overall system
physical memory usage would be significantly increased, reducing the
capacity of the machine because of all the duplicated text (code).

[toc] | [prev] | [next] | [standalone]

#104876

W dniu poniedziałek, 27 lutego 2017 16:20:10 UTC+1 użytkownik Scott Lurndal napisał:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> >On Sun, 26 Feb 2017 14:40:17 +0100
> >David Brown <david.brown@hesbynett.no> wrote:
> >
> >> The "-static" flag for gcc asks it to use static linking rather than 
> >> using dynamic .so libraries.  You have to have the right static 
> >> libraries available, of course.  Static linking can result in 
> >> executables that are marginally faster, and they become independent of 
> >> the .so files - but they are /much/ bigger.  (On my system, a "Hello 
> >> world" with dynamic linking is about 8.6K, with static linking it is 900K.)
> >
> >Maybe 900 kilo-octets is sensibly bigger than 8,6 kilo-octets but it is
> >ridiculous to save 891,4 kilo-octets with common storage medias over
> >1 Tera-octets while wasting processor's time in loading libraries.
> 
> The key advantage of shared objects are that the text page(s) for the

the key advantage of shared objects is that some libraries must be shared
(do you imagine static linking to device drivers? not really)

other advantage is that dynamic libraries 
are nice for developing.. i personally quite like dll's,  [though personally i would probably like the option to link-it in statically [im not quite sure if this not impossible today] as i once said i probably would like static .obj and dynamic .dll be just the same files [even today differences seem slight]]

> shared object can be shared between all processes/threads on the system
> reducing the physical memory footprint of all processes.  Consider libc,
> which is shared by pretty much every process on the system - if each had
> their own subset because they were statically linked, the overall system
> physical memory usage would be significantly increased, reducing the
> capacity of the machine because of all the duplicated text (code).

[toc] | [prev] | [next] | [standalone]

#104884

W dniu poniedziałek, 27 lutego 2017 16:45:27 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 27 lutego 2017 16:20:10 UTC+1 użytkownik Scott Lurndal napisał:
> > GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> > >On Sun, 26 Feb 2017 14:40:17 +0100
> > >David Brown <david.brown@hesbynett.no> wrote:
> > >
> > >> The "-static" flag for gcc asks it to use static linking rather than 
> > >> using dynamic .so libraries.  You have to have the right static 
> > >> libraries available, of course.  Static linking can result in 
> > >> executables that are marginally faster, and they become independent of 
> > >> the .so files - but they are /much/ bigger.  (On my system, a "Hello 
> > >> world" with dynamic linking is about 8.6K, with static linking it is 900K.)
> > >
> > >Maybe 900 kilo-octets is sensibly bigger than 8,6 kilo-octets but it is
> > >ridiculous to save 891,4 kilo-octets with common storage medias over
> > >1 Tera-octets while wasting processor's time in loading libraries.
> > 
> > The key advantage of shared objects are that the text page(s) for the
> 
> the key advantage of shared objects is that some libraries must be shared
> (do you imagine static linking to device drivers? not really)
> 
> other advantage is that dynamic libraries 
> are nice for developing.. i personally quite like dll's,  [though personally i would probably like the option to link-it in statically [im not quite sure if this not impossible today] as i once said i probably would like static .obj and dynamic .dll be just the same files [even today differences seem slight]]
> 


btw i recently encountered a related problem though (not to emntion other problem of circullar dependency it is possible that to compile dll A you need 
dll B be present/compiled and if you need 
A be compiled to compile B you could not
compile it at all ;C this is some nightmare, i dont even exactly inspected 
what is a reason for that)

other problem is that in some cases you
need to export function from exe and
exe disallows that (which is probably bad
design decision) so you need just 
need turn your exe in a dll and add some fake exe for starting that and this is artificial (more on this maybe later aa
i recently was doin just this code )

> > shared object can be shared between all processes/threads on the system
> > reducing the physical memory footprint of all processes.  Consider libc,
> > which is shared by pretty much every process on the system - if each had
> > their own subset because they were statically linked, the overall system
> > physical memory usage would be significantly increased, reducing the
> > capacity of the machine because of all the duplicated text (code).

[toc] | [prev] | [next] | [standalone]

#104822

On 02/26/2017 05:10 PM, David Brown wrote:
> On 26/02/17 09:31, MehdiAmini wrote:
>> Hi,
>>
>> I am on a Ubuntu Linux PC. Using Code::Blocks IDE and Clang compiler. My
>> compiled projects produce executive console files that depend on dynamic
>> library .so files. How can I produce executive files that do not depend
>> on these .so files?
>>
>
> The "-static" flag for gcc asks it to use static linking rather than
> using dynamic .so libraries.

[...]

Thanks, this seems to work for me:

In Code::Blocks IDE and Clang compiler, click Settings 
menu/Compiler.../Linker settings/Other linker options:/ add -static then 
press OK.

-- 
Farewell.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web