Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of RYAN_NEAL@appsig.com designates
 63.124.185.41 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Cross compiling the APR suite
Date: Thu, 21 Jan 2010 14:43:01 -0800
Message-ID: <4B2CB099CF3D4F40B1B1442281CA94FFD99CFF@EXCHANGEVS01.appsig.com>
In-Reply-To: <4B58D7EF.9010000@redfish-solutions.com>
Thread-Topic: Cross compiling the APR suite
Thread-Index: Acqa6uT5sZCalUsCR8mN4AikhJ63awAAAazg
References: <4B2CB099CF3D4F40B1B1442281CA94FFD99BCA@EXCHANGEVS01.appsig.com>
 <5944A430-18EE-4051-B16F-E451AA50F40F@apache.org>
 <4B56E332.7030201@pocock.com.au>
 <4B2CB099CF3D4F40B1B1442281CA94FFD99C64@EXCHANGEVS01.appsig.com>
 <4B5802AF.1090005@redfish-solutions.com>
 <4B2CB099CF3D4F40B1B1442281CA94FFD99CFE@EXCHANGEVS01.appsig.com>
 <4B58D7EF.9010000@redfish-solutions.com>
From: "NEAL, RYAN" <RYAN_NEAL@appsig.com>
To: "Philip A. Prindeville" <philipp_subx@redfish-solutions.com>
Cc: <dev@apr.apache.org>

I didn't add it intentionally. =20

In looking at the config.log it is there.  The compile line looks like
this roughly:

1074 configure:48947: powerpc-linux-uclibc-gcc -o conftest -g -O2
-DLINUX=3D2 -D_REENTRANT -D_GNU_SOURCE
-L/tmp/buildroot-2009.11/output/target/lib
-L/tmp/buildroot-2009.11/output/target/usr/lib conftest.c  >&5

:: Ryan Neal


-----Original Message-----
From: Philip A. Prindeville [mailto:philipp_subx@redfish-solutions.com]=20
Sent: Thursday, January 21, 2010 2:41 PM
To: NEAL, RYAN
Cc: dev@apr.apache.org
Subject: Re: Cross compiling the APR suite

Do you need -D_GNU_SOURCE in your $CFLAGS?


On 01/21/2010 02:38 PM, NEAL, RYAN wrote:
> Philip,
>=20
> Thanks for the advice.  I went into the buildroot and had it compile
> iconv.  This allowed me to have an iconv that is cross-compiled
already.
> I tried doing it myself - just another headache...
>=20
> What I had to do was NOT provide the --with-iconv flag and add the
> LDFLAGS=3D"-L/tmp/buildroot-2009.11/output/target/lib
> -L/tmp/buildroot-2009.11/output/target/usr/lib" flag.  This is where
the
> libiconv.so resided.  This worked beautifully.  And then the compile
on
> the log4cxx worked as well.=20
>=20
> Still having a problem linking against the pthread library (in the
same
> spot as the iconv lib) but that is a log4cxx problem.
>=20
> I was wondering where the possibilities for PACKAGE were
> (--with-PACKAGE)? =20
>=20
> Thanks soooo much!  I couldn't have done this without you guys!
>=20
> :: Ryan Neal
>=20
>=20
> -----Original Message-----
> From: Philip A. Prindeville
[mailto:philipp_subx@redfish-solutions.com]=20
> Sent: Wednesday, January 20, 2010 11:31 PM
> To: dev@apr.apache.org
> Subject: Re: Cross compiling the APR suite
>=20
> You might need to use:
>=20
> -isystem /xyzzy
>=20
> for your CFLAGS, where "/xyzzy" is the prefix to your target's include
> directory, and:
>=20
> --sysroot=3D/barfoo -L/barfoo/lib
>=20
> (or whatever) for your LDFLAGS to find the right libraries.
>=20
>=20
> On 01/20/2010 04:30 PM, NEAL, RYAN wrote:
>> Hey,
>>
>> So after some investigation I have found something that I think is a
>> problem...I have work around that gets me closer but it isn't there
> yet.
>>
>> When APU is trying to determine iconv "presence" it will write a
> little
>> program and try and compile it.  The file is just to determine if the
>> included files are there.  What ends up happening when I am cross
>> compiling is that iconv.h includes features.h which includes
>> gnu/stubs-32.h.  When it tries this it is relying on the build
> machine's
>> install.  I am building on a F11 64bit machine.  Thus I have a
>> stubs-64.h, but no stubs-32.h.  I went and got a stubs-32.h from
> another
>> Red Hat machine, this allows me to get to the point where it tries to
>> find the libiconv file (-liconv).  This is failing. =20
>>
>> I am not sure where I can get a copy of this.  Do I not have a iconv
>> installed on the machine?  I thought it came with the F11 install.=20
>>
>> Again thanks for helping!
>>
>> :: Ryan Neal
>>
>>
>> -----Original Message-----
>> From: Daniel Pocock [mailto:daniel@pocock.com.au]=20
>> Sent: Wednesday, January 20, 2010 3:04 AM
>> To: Nick Kew
>> Cc: NEAL, RYAN; dev@apr.apache.org
>> Subject: Re: Cross compiling the APR suite
>>
>>
>> I've attempted cross compiling with the Android NDK and the NDK
>> wrappers.
>>
>> There were a few things I had to tweak, I will publish some details=20
>> shortly.  Some of what I did will be necessary for any cross-compile,

>> not just Android.
>>
>> Nick Kew wrote:
>>  =20
>>> On 20 Jan 2010, at 01:02, NEAL, RYAN wrote:
>>>
>>>  =20
>>>    =20
>>>> Hello,
>>>>    =20
>>>>      =20
>>> Your mail would be more legible it you can stop your mailer
>>> scrambling it into pseudo-HTML.
>>>
>>>  =20
>>>    =20
>>>> ./configure CC=3Dpowerpc-linux-gcc --host=3Dpowerpc-linux
>>>>      =20
>> --prefix=3D/tmp/target_filesystem/apr ac_cv_file__dev_zero=3Dyes
>> ac_cv_func_setpgrp_void=3Dyes apr_cv_tcp_nodelay_with_cork=3Dyes
>> ac_cv_sizeof_struct_iovec=3D8 --enable-threads =
CXX=3Dpowerpc-linux-g++
>>  =20
>>>>    =20
>>>>      =20
>>> Is this a cross-compile you're attempting?  If not, whence all those
>>>    =20
>> settings?
>>  =20
>>>  =20
>>>    =20
>>>> /tmp/target_filesystem/apr/lib/libapr-1.so: warning: the use of
>>>>      =20
>> LEGACY `utimes' is discouraged, use `utime'
>>  =20
>>>>    =20
>>>>      =20
>>> Could be worth following up ...
>>>
>>>  =20
>>>    =20
>>>> /tmp/target_filesystem/apr/lib/libapr-1.so: undefined reference to
>>>>      =20
>> `pthread_create'
>>  =20
>>>>    =20
>>>>      =20
>>> So it's compiled libapr with pthread for the target system but
> doesn't
>>>    =20
>> find it
>>  =20
>>> on the host system.  Maybe it would help if you point your
--with-apr
>>> to the target apr's apr-1-config?
>>>
>>>  =20
>>>    =20
>>>> Any ideas would be REALLY helpful.   I am stumped!
>>>>    =20
>>>>      =20
>>> If we knew what you're really trying to do ....
>>>
>>> Find exactly what failed in config.log.  Then try the same thing by
>>>    =20
>> hand,
>>  =20
>>> and tweak that until you have it working.  You can then work
> backwards
>>> to the build options and/or patches you may need.
>>>
>>>  =20
>>>    =20
>>  =20
>=20