Quantcast

ported packages : new version

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ported packages : new version

Vincent Torri

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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Danny Backx
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


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Vincent Torri

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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Pedro Alves-5
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Vincent Torri


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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Pedro Alves-5
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Vincent Torri


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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Dave Korn-2
In reply to this post by Pedro Alves-5
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


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ported packages : new version

Pedro Alves-5
In reply to this post by Vincent Torri
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

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Loading...