Do you need -D_GNU_SOURCE in your $CFLAGS?
On 01/21/2010 02:38 PM, NEAL, RYAN wrote:
> Philip,
>
> 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...
>
> What I had to do was NOT provide the --with-iconv flag and add the
> LDFLAGS="-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.
>
> Still having a problem linking against the pthread library (in the same
> spot as the iconv lib) but that is a log4cxx problem.
>
> I was wondering where the possibilities for PACKAGE were
> (--with-PACKAGE)?
>
> Thanks soooo much! I couldn't have done this without you guys!
>
> :: Ryan Neal
>
>
> -----Original Message-----
> From: Philip A. Prindeville [mailto:philipp_subx@redfish-solutions.com]
> Sent: Wednesday, January 20, 2010 11:31 PM
> To: dev@apr.apache.org
> Subject: Re: Cross compiling the APR suite
>
> You might need to use:
>
> -isystem /xyzzy
>
> for your CFLAGS, where "/xyzzy" is the prefix to your target's include
> directory, and:
>
> --sysroot=/barfoo -L/barfoo/lib
>
> (or whatever) for your LDFLAGS to find the right libraries.
>
>
> 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.
>>
>> 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.
>>
>> Again thanks for helping!
>>
>> :: Ryan Neal
>>
>>
>> -----Original Message-----
>> From: Daniel Pocock [mailto:daniel@pocock.com.au]
>> 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
>> shortly. Some of what I did will be necessary for any cross-compile,
>> not just Android.
>>
>> Nick Kew wrote:
>>
>>> On 20 Jan 2010, at 01:02, NEAL, RYAN wrote:
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>>
>>> Your mail would be more legible it you can stop your mailer
>>> scrambling it into pseudo-HTML.
>>>
>>>
>>>
>>>> ./configure CC=powerpc-linux-gcc --host=powerpc-linux
>>>>
>> --prefix=/tmp/target_filesystem/apr ac_cv_file__dev_zero=yes
>> ac_cv_func_setpgrp_void=yes apr_cv_tcp_nodelay_with_cork=yes
>> ac_cv_sizeof_struct_iovec=8 --enable-threads CXX=powerpc-linux-g++
>>
>>>>
>>>>
>>> Is this a cross-compile you're attempting? If not, whence all those
>>>
>> settings?
>>
>>>
>>>
>>>> /tmp/target_filesystem/apr/lib/libapr-1.so: warning: the use of
>>>>
>> LEGACY `utimes' is discouraged, use `utime'
>>
>>>>
>>>>
>>> Could be worth following up ...
>>>
>>>
>>>
>>>> /tmp/target_filesystem/apr/lib/libapr-1.so: undefined reference to
>>>>
>> `pthread_create'
>>
>>>>
>>>>
>>> So it's compiled libapr with pthread for the target system but
> doesn't
>>>
>> find it
>>
>>> on the host system. Maybe it would help if you point your --with-apr
>>> to the target apr's apr-1-config?
>>>
>>>
>>>
>>>> Any ideas would be REALLY helpful. I am stumped!
>>>>
>>>>
>>> If we knew what you're really trying to do ....
>>>
>>> Find exactly what failed in config.log. Then try the same thing by
>>>
>> hand,
>>
>>> and tweak that until you have it working. You can then work
> backwards
>>> to the build options and/or patches you may need.
>>>
>>>
>>>
>>
>
|