[reSIProcate] resiprocate-devel Digest, Vol 48, Issue 18

[Mandeep Ahuja]

Ok, I hope this will answer the question
Output of Ares config options:
--build=x86 --host=mips-linux 
CC=/home/ahuja/aksys/tools/linux/bin/mips_fp_le-gcc 
AR=/home/ahuja/aksys/tools/linux/bin/mips_fp_le-ar rcs 
CFLAGS=-D__DEBUG__ -Dassert=ASSERT -I/home/ahuja/aksys/phoneApp/shared 
-g -ggdb -O0  RANLIB=/home/ahuja/aksys/tools/linux/bin/mips_fp_le-ranlib

Resip Config options are:
 -C --build=x86 --host=mips-linux 
CXX=/home/ahuja/aksys/tools/linux/bin/mips_fp_le-g++ 
CXXFLAGS=-D__DEBUG__ -Dassert=ASSERT -I/home/ahuja/aksys/phoneApp/shared 
-g -ggdb -O0  
--with-ares=/home/ahuja/aksys/phoneApp/libraries/dum/main/sip/contrib/ 
LDFLAGS=-L/home/ahuja/aksys/phoneApp/libraries/dum/main/sip/contrib/ares/mips

The above is from resiprocate's first version 0.99 I think. I am trying 
to get the latest one running with the mips tools.

Thanks for bearing with me Adam.

Waiting....

Adam Roach wrote:

> On 4/28/08 2:00 PM, Mandeep Ahuja wrote:
>
>> Ok Let me get this right. Lets try where I dont have to use the 
>> autotools
>
>
> I think you misunderstand what I'm asking. Ares uses autotools, so we 
> don't have any option here -- we need to be able to run ./configure 
> for ares so that ares can be built. I've not worked with build 
> environments in which the name of the compiler differed from the name 
> of the platform. It's just not a problem I've ever encountered, so I 
> don't know how to solve it. Apparently, you *do* know how to solve it, 
> because it's the environment you're working in.
>
> So.
>
> I think I can fix the problem you're encountering if you can clearly, 
> concisely, and accurately answer just one question: With your 
> environment, what would you literally type in to the commandline to 
> configure ares to build? (In your answer, include the output of the 
> configure command so I know what I should expect to see).
>
> /a
>
>
>
>> (might see a problem again future)
>> --host=mips-linux
>> corss_compile = ~/tools/linux/bin/mips_fp_le-
>> the cross compiler is "mips_fp_le"
>> Also when i was trying to make 'rutil' it complained about not 
>> finding 'ostream' which is in
>> ~/tools/linux/target/user/include/g++-3/ directory.
>>
>> I hope that can be of some help
>> Mandeep
>>
>> Adam Roach wrote:
>>
>>> I'll see if I can fix this fairly quickly -- what are the exact 
>>> options that you would expect to pass to an autotools-generated 
>>> ./configure script to set the compiler correctly? Is it simply 
>>> "./configure --host=mips_fp_le"? I'll admit that my knowledge of 
>>> autotools is a bit meager; but, as far as I know, the only way to 
>>> trigger cross compilation with autotools is to pass it the name of 
>>> the architecture with the "--host" flag -- and it does the same 
>>> thing with it as the resip build system does: it prepends it to the 
>>> names of the various gnu toolchain binaries, and tries it to see 
>>> whether it works.
>>>
>>> In other words: I can split the target platform option into two 
>>> different options (target platform and cross-compiler prefix) if 
>>> that's what you need to suit your purposes, but I don't know enough 
>>> about the autotools systems that I need to pass options into (such 
>>> as ares) to know what to pass where and how.
>>>
>>> /a
>>>
>>> On 4/28/08 12:08 PM, Mandeep Ahuja wrote:
>>>
>>>> Thanks for the heads up Adam,
>>>> Here is the first problem
>>>> 1- The architecture-ostype (in my case mips-linux) does not match 
>>>> with platform string in the name of my cross compiler 
>>>> (mips_fp_le-gcc). I dont plan to change either of the names as I 
>>>> have lot going on already. What can I do to get around?
>>>> Here is a little sample output
>>>> mkdir -p contrib/ares-build.Linux.mips
>>>> cd contrib/ares-build.Linux.mips && \
>>>>  ../ares/configure   --host=mips-linux
>>>> configure: WARNING: If you wanted to set the --build type, don't 
>>>> use --host.
>>>>    If a cross compiler is detected then cross compile mode will be 
>>>> used.
>>>> Configuring ares 1.1.2
>>>> checking for a BSD-compatible install... /usr/bin/install -c
>>>> checking whether build environment is sane... yes
>>>> checking for gawk... gawk
>>>> checking whether make sets $(MAKE)... yes
>>>> checking for mips-linux-strip... no
>>>> checking for strip... strip
>>>> checking for mips-linux-gcc... no
>>>> checking for gcc... gcc
>>>> checking for C compiler default output file name... a.out
>>>> checking whether the C compiler works... yes
>>>> checking whether we are cross compiling... no
>>>> checking for suffix of executables...
>>>> checking for suffix of object files... o
>>>> checking whether we are using the GNU C compiler... yes
>>>> checking whether gcc accepts -g... yes
>>>> checking for gcc option to accept ANSI C... none needed
>>>> checking for style of include used by make... GNU
>>>> checking dependency style of gcc... gcc3
>>>> checking for a BSD-compatible install... /usr/bin/install -c
>>>> checking whether make sets $(MAKE)... (cached) yes
>>>> checking for mips-linux-ranlib... no
>>>> checking for ranlib... ranlib
>>>> checking build system type... i686-pc-linux-gnu
>>>> checking host system type... mips-unknown-linux-gnu
>>>>
>>>> Adam Roach wrote:
>>>>
>>>>> Mandeep Ahuja wrote:
>>>>>
>>>>>> I need the autotools scripts that you guys had earlier. Remember 
>>>>>> the 'use_autotools.sh' and 'auto_gen.sh'. I can't find them in 
>>>>>> the latest checkout. I think last time i checked out was in 2004. 
>>>>>> If noone has it will the old one work with the new revision. I am 
>>>>>> doing cross-compiling.
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The autotools setup never really got completed (at least, not to 
>>>>> everyone's satisfaction), and has been pulled out of the 
>>>>> repository for a long time now. Even if you can find a copy, I do 
>>>>> _not_ suggest you use it. It is highly doubtful that it will work 
>>>>> with the current tree (which has been vigorously reorganized since 
>>>>> the last time anyone tried autotools) -- at least, not without a 
>>>>> lot of effort.
>>>>>
>>>>> You're not stuck, though. The current build system has pretty good 
>>>>> support for cross compilation using the gnu toolchain. Run the 
>>>>> configure script (in the root of the project tree); when it asks 
>>>>> which toolchain you plan on using, answer "gnu-cross." It will 
>>>>> then prompt you for the path to the cross compiler and the name of 
>>>>> the platform formatted as architecture-ostype (e.g., "arm-linux"). 
>>>>> This platform name must match the platform string in the name of 
>>>>> your cross compiler. (i.e., if your cross compiler is called 
>>>>> "arm-linux-gcc", then your platform is called "arm-linux").
>>>>>
>>>>> If you have any problems with the cross-compilation support in the 
>>>>> existing build system, post here about it so we can try to make 
>>>>> things work better.
>>>>>
>>>>> /a
>>>>>
>>>>
>>>
>>>
>>
>
>