Slow xfrun, [was: new dev branch stuff]

[edscott wilson garcia]

Enough speculation. I've just done a field test and verified that you
are right, dynamic library is prefered and the static version will not
be used unless explicitly told. Furthermore, if you dynamically link to
a library which in turn is dynamically linked to another library, you
may not link statically to this second library instead of dynamically.
Although that does not appear obvious, it makes sense. 

Which all brings us back to the issue at hand, using static libraries
for xfrun might not be the magic bullet to cut down startup time. Any
other suggestions to cut down startup time? 

regards,

Edscott 


El dom, 23-01-2005 a las 13:23 -0500, Antonio SJ Musumeci escribió:
> you can find out exactly what the executable contains by using nm or to 
> see what librarys a dynamically linked executable uses with ldd. gcc has 
> a default mode... which is usually shared. I dont think gcc will have 
> something statically linked without being told. And from playing around 
> gcc is all or nothing unlike ld... "gcc -shared blah.c -static -lm" 
> gives you libm dynamically linked.
> 
> i dont believe ld knows what language the code was created from... if 
> you read the man page for ld... there are some options used for C++... 
> but they appear optional.
> 
> as for cpp... my comment was that it is simply the C preprocessor... not 
> a front end to the gnu compiler suite for the C++ language. every unix 
> platform i'ved used cpp was the c preprocessor. c++ was the c++ compiler 
> or front end.
> 
> 
> edscott wilson garcia wrote:
> > El dom, 23-01-2005 a las 10:48 -0500, Antonio SJ Musumeci escribió:
> > 
> >>a.out can be linked dynamically. elf can be linked statically. ld doesnt 
> >>"fall back" to static if it cant find the dynamic library. Nor the 
> >>opposite. cpp is the C preprocessor... not the c++ compiler.
> >>
> >>http://en.wikipedia.org/wiki/Object_file_format
> >>
> > 
> > 
> > I generate elf format on my box and use -lm frequently with no problems
> > although I do not have any libm.so. So, if you specify -lm, since ld
> > does not "fall back" to libm.a, the default must be static, then? 
> > 
> > Further, I never said elf format could not be linked statically, that
> > would be daft. If a.out can now be linked dynamically, I stand
> > corrected, but AFAICR, linux kernel 1.x was a.out format. The move with
> > kernel 2.0 to elf format was for a good reason: the ability to load
> > modules dynamically. Back then a.out was not dynamically linkable. Maybe
> > now it is, from what you found out. Dynamic linking for the i86
> > architecture did not appear until the last decade of the past century
> > (which sounds like a long time ago, but is not). 
> > 
> > cpp might be a preprocessor, and in GNU, so is g77. But this not
> > necessarily applies everywhere. There are many fortran compilers out
> > there which are true compilers.
> > 
> > Even so, that is a moot point, since you must invoke the preprocessor to
> > compile c++, which brings us back to the point where it is entirely
> > plausible for ld to know what language the code is being linked from
> > when the executable is created, which was the point being discussed.
> > Nothing more. That, of course, if you do not invoke ld directly. 
> > 
> > 
> > 
> >  
> > 
> > 
> >>edscott wilson garcia wrote:
> >>
> >>
> >>>Whether ld chooses static or dynamic would also depend on the executable
> >>>output format as well. a.out cannot be linked dynamically, elf format
> >>>can. The default is probably chosen on the output type, static for a.out
> >>>and dynamic for elf (and falling back to the .a file if the .so file is
> >>>not present). The language choice could be made by ld if called from cc
> >>>or cpp or f77 (I never invoke ld directly myself), but I've never
> >>>checked this on point (although I eventually will, just out of
> >>>curiousity).
> >>>
> >>> 
> >>>regards,
> >>>
> >>>Edscott
> >>>_______________________________________________
> >>>Xfce4-dev mailing list
> >>>Xfce4-dev at xfce.org
> >>>http://lunar-linux.org/mailman/listinfo/xfce4-dev
> >>>
> >>
> >>_______________________________________________
> >>Xfce4-dev mailing list
> >>Xfce4-dev at xfce.org
> >>http://lunar-linux.org/mailman/listinfo/xfce4-dev
> >>
> 
-- 
edscott wilson garcia <edscott at xfce.org>