Re: Auto Repair Cross Includes?

Hi Ned,

I like the patch - there are probably many cases where a package does
not cross compile properly when include paths are not fixed. In those
cases, it would be necessary to patch the source on an
ebuild-by-ebuild basis. This would eliminate the need to fix the files
at an ebuild level with a relatively inexpensive check.

Mike has a couple of good points too - unless it's necessary to use
thee function from outside gcc or whatever library it ends up in, it
may as well be marked static. Path vs name ? I think path. Regarding
arbitrary non-standard include paths that could generate false
positives, i have no comment.

Regarding path normalization ( "//" => "/" ) - in my opinion, if gcc
doesn't already do it, then forget about it - otherwise one would be
obliged to fix it for the rest of gcc, no? Keep it short and simple.

Depending on the level of community feedback you want, I could help
test for a while, or you could just include it in an unstable ~ gcc
version and see how the universe reacts to it :)

Regards,

Chris

On Sun, Sep 21, 2008 at 12:12 PM, Ned Ludd <solar@...> wrote:
> I've been toying with an idea after seeing a patch which would abort()
> when it detected host includes for cross compiles. I did not like the
> idea of aborting as it prevented me from building pkgs that had the same

[OT] gcc and memory models

Sorry for this off-topic question

Can anyone point me so any resource on how do I tell gcc which RAM I
want to use in a microcontroller that has its own internal few kbytes
of RAM, but to which I've connected an external chip?

I know this is possible, because it is a sample architecture from the
microcontroller manufacturer datasheet, but I got no source code along
with this example.

thanks a lot
Francisco

Re: Auto Repair Cross Includes?

On Thu, 2009-02-05 at 10:32 -0500, Christopher Friedt wrote:
> Hi Ned,
> 
> I like the patch - there are probably many cases where a package does
> not cross compile properly when include paths are not fixed. In those
> cases, it would be necessary to patch the source on an
> ebuild-by-ebuild basis. This would eliminate the need to fix the files
> at an ebuild level with a relatively inexpensive check.
> 
> Mike has a couple of good points too - unless it's necessary to use
> thee function from outside gcc or whatever library it ends up in, it
> may as well be marked static. Path vs name ? I think path. Regarding
> arbitrary non-standard include paths that could generate false
> positives, i have no comment.
> 
> Regarding path normalization ( "//" => "/" ) - in my opinion, if gcc
> doesn't already do it, then forget about it - otherwise one would be
> obliged to fix it for the rest of gcc, no? Keep it short and simple.
> 
> Depending on the level of community feedback you want, I could help
> test for a while, or you could just include it in an unstable ~ gcc
> version and see how the universe reacts to it :)

I'm all for these things. But to be honest time is limited and I've not
been having too much trouble simply using -I${ROOT}/usr/include. Every
so often a I'll need to add a non standard python include path. But it's
been easy enough to work around.

Anyway feel free to recode up a better patch to address the points you
and others have pointed out.

Re: [OT] gcc and memory models

On Thursday 05 February 2009 17:09:21 Francisco Ares wrote:
> Can anyone point me so any resource on how do I tell gcc which RAM I
> want to use in a microcontroller that has its own internal few kbytes
> of RAM, but to which I've connected an external chip?

void *some_weird_ram = 0x1235235;
-mike

Re: GCC 4.3 fails on mpfr

Hi there, sorry for writing again on this issue, but I have not been able to
solve the problem with the configure command on GCC 4.3 due to the
dependency on MPFR and GMP.

I have them both installed correctly and the headers are in their own build
directories, while the library files (*.a) are in /usr/local/lib.
This verified, I tried different options among which the following,

../configure --with-gmp=/Users/simone/myApplications/gmp-4.2.4/
--with-gmp-lib=/usr/local/lib/libgmp.a
--with-mpfr=/Users/simone/myApplications/mpfr-2.4.0/
--with-mpfr-lib=/usr/local/lib/libmpfr.a

but obtaining again the same error from the configure call:

configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

Why is this happening? What is it that I am not telling the configure to do
?

Thank you in advance
S.M.

Re: GCC 4.3 fails on mpfr

On Monday 09 February 2009 08:40:06 bscuser wrote:
> Hi there, sorry for writing again on this issue, but I have not been able
> to solve the problem with the configure command on GCC 4.3 due to the
> dependency on MPFR and GMP.

just emerge mpfr and gmp

> I have them both installed correctly and the headers are in their own build
> directories, while the library files (*.a) are in /usr/local/lib.

why ?  the ones you `emerge` should work fine.
-mike

Re: GCC 4.3 fails on mpfr

Hi there, thanks for replying. How do I merge them? What does it exactly
mean? when I command "mergelib mpfr" I obtain "usage:  /usr/bin/mergelib 
to-library from-library [object-filename-prefix]" where I do not know what
the to-library would be in this case.

I am sorry about the questions, but I am a beginner in all this.
I hope you can help

Best
S.M.

Mike Frysinger wrote:
> 
> On Monday 09 February 2009 08:40:06 bscuser wrote:
>> Hi there, sorry for writing again on this issue, but I have not been able
>> to solve the problem with the configure command on GCC 4.3 due to the
>> dependency on MPFR and GMP.
> 
> just emerge mpfr and gmp
> 
>> I have them both installed correctly and the headers are in their own
>> build
>> directories, while the library files (*.a) are in /usr/local/lib.
> 
> why ?  the ones you `emerge` should work fine.
> -mike
> 
> 
> 

libnss_dns.so

Re: libnss_dns.so

Abdolmohaimen Siddig wrote:
> hello
> I am trying to run dhcp server under uclibc environment, the package
> dhcp merges successfully but when I try to start the service (
> /etc/init.d/dhcp start ) it tells me that the shared library
> libnss_dns.so can not be loaded. I investigate the mater and find that
> the following shared library can not be built : ( libnss_dns,
> libresolv.so, libc.so, and ld.so ) please tell me what to do to get
> these shared library into my system
>
> best regards
> A.mohaimen
Those should be uclibc libs..  You don't have uclibc installed on your
target.

Re: libnss_dns.so

Abdolmohaimen Siddig wrote:
> the following shared library can not be built :
> ( libnss_dns, libresolv.so, libc.so, and ld.so )
> please tell me what to do to get these shared library into my system

That is completely impossible without more information. If you can
provide more information about the failed build maybe we can help.

//Peter