Menu
▾
▴
cegcc-devel
|
From: Vincent T. <vt...@un...> - 2010-01-26 14:03:21
|
there are currently 4 ported packages (zlib, libjpeg, libpng and freetype). Each of them have new versions (excepted zlib, but it will be soon). So i want to provide new packages. I would like advices on the flags i should use, not use, for optimisations (in speed, mainly). In each tarball, i have added a README file, with a complete description of the built. Can you comment them ? other questions : should i build several packages for different arch (armV etc...) is there something specific to do for x86 ? thank you Vincent Torri |
|
From: Danny B. <dan...@sc...> - 2010-01-30 07:07:41
|
On Tue, 2010-01-26 at 14:35 +0100, Vincent Torri wrote: > there are currently 4 ported packages (zlib, libjpeg, libpng and > freetype). Each of them have new versions (excepted zlib, but it will be > soon). So i want to provide new packages. Great. > I would like advices on the flags i should use, not use, for optimisations > (in speed, mainly). Not sure what to say. Is "-g -O" a good idea ? > In each tarball, i have added a README file, with a > complete description of the built. Can you comment them ? I may have missed something, I assume you want us to comment on the new versions but I don't know where they are. > other questions : > > should i build several packages for different arch (armV etc...) I would advice against compiling for specific versions of ARM. If anyone needs that, they can do the extra step themselves. > is there something specific to do for x86 ? Apart from using the other compiler, I don't think so. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Vincent T. <vt...@un...> - 2010-01-30 07:14:04
|
Hey, On Sat, 30 Jan 2010, Danny Backx wrote: > On Tue, 2010-01-26 at 14:35 +0100, Vincent Torri wrote: >> there are currently 4 ported packages (zlib, libjpeg, libpng and >> freetype). Each of them have new versions (excepted zlib, but it will be >> soon). So i want to provide new packages. > > Great. > >> I would like advices on the flags i should use, not use, for optimisations >> (in speed, mainly). > > Not sure what to say. Is "-g -O" a good idea ? -g is not an option. The dll would be too big. The fact that a dll takes in memory a multiple of 64KB is already a problem. >> In each tarball, i have added a README file, with a >> complete description of the built. Can you comment them ? > > I may have missed something, I assume you want us to comment on the new > versions but I don't know where they are. no :-) I would like that people comment on the current packages options. I planned to use the same flags, but maybe there are things that are useless or wrong, others that are missing, etc... >> should i build several packages for different arch (armV etc...) > > I would advice against compiling for specific versions of ARM. If anyone > needs that, they can do the extra step themselves. ok >> is there something specific to do for x86 ? > > Apart from using the other compiler, I don't think so. ok thank you Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-01-30 11:19:38
|
On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: > -g is not an option. The dll would be too big. The fact that a dll takes > in memory a multiple of 64KB is already a problem. ??? The data -g puts in the dll doesn't contribute a single byte to what the dll takes in memory. -- Pedro Alves |
|
From: Vincent T. <vt...@un...> - 2010-01-30 17:41:54
|
On Sat, 30 Jan 2010, Pedro Alves wrote: > On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: > >> -g is not an option. The dll would be too big. The fact that a dll takes >> in memory a multiple of 64KB is already a problem. > > ??? The data -g puts in the dll doesn't contribute a single byte > to what the dll takes in memory. ok, but runtime startup is a lot bigger Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-01-30 17:52:24
|
On Saturday 30 January 2010 17:41:41, Vincent Torri wrote: > > On Sat, 30 Jan 2010, Pedro Alves wrote: > > > On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: > > > >> -g is not an option. The dll would be too big. The fact that a dll takes > >> in memory a multiple of 64KB is already a problem. > > > > ??? The data -g puts in the dll doesn't contribute a single byte > > to what the dll takes in memory. > > ok, but runtime startup is a lot bigger What's runtime startup? There's no reason to copy a dll with debug info to the device. You can copy a stripped version, and keep the version with debug info in the host. Of course, if you want to provide a prebuilt dll with debug info to users, you can also provide an already pre-stripped dll. -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-30 18:46:52
|
On 30/01/2010 17:52, Pedro Alves wrote:
> There's no reason to copy a dll with debug info to
> the device. You can copy a stripped version, and keep
> the version with debug info in the host.
>
> Of course, if you want to provide a prebuilt dll with
> debug info to users, you can also provide an
> already pre-stripped dll.
Another option: supply a stripped DLL and a separate .DBG, which the DLL
refers to in a .GNU.debuglink section - see the objcopy options
'--only-keep-debug' and '--add-gnu-debuglink=PATH-TO-FILE'. That way you only
have one DLL to worry about.
cheers,
DaveK
|
|
From: Vincent T. <vt...@un...> - 2010-01-30 18:39:32
|
On Sat, 30 Jan 2010, Pedro Alves wrote: > On Saturday 30 January 2010 17:41:41, Vincent Torri wrote: >> >> On Sat, 30 Jan 2010, Pedro Alves wrote: >> >>> On Saturday 30 January 2010 07:13:55, Vincent Torri wrote: >>> >>>> -g is not an option. The dll would be too big. The fact that a dll takes >>>> in memory a multiple of 64KB is already a problem. >>> >>> ??? The data -g puts in the dll doesn't contribute a single byte >>> to what the dll takes in memory. >> >> ok, but runtime startup is a lot bigger > > What's runtime startup? time spent during startup. Sorry > > There's no reason to copy a dll with debug info to > the device. You can copy a stripped version, and keep > the version with debug info in the host. > > Of course, if you want to provide a prebuilt dll with > debug info to users, you can also provide an > already pre-stripped dll. Ok, i restart : 1) Can people read the README file of the current packages to see if the flags are good or not, useless or not, etc... ? 2) Can people tell me which flags i should use to optimize the built for speed ? Pedro, if you have, once, untar the ported package, you should have remarked that i provide the dll, and they are stripped (see README file...). thank you Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-01-30 19:00:54
|
On Saturday 30 January 2010 18:39:25, Vincent Torri wrote: > Pedro, if you have, once, untar the ported package, you should have > remarked that i provide the dll, and they are stripped (see README > file...). Pasting the relevant bits of the file in the email body goes a long way torwards making it much easier for people to actually read it, and so greatly increases the chances of actually getting people to provide input. Requiring a download, untar, and opening the file, and then quote it on replies is just bloat in the process, which kills people's time. I'll try to get to it if you don't paste the file for some reason, but not now. -- Pedro Alves |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X