Re: GCC 4.8 libcpp Issue...Possibly Related To (FIXED)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 27, 2013 at 6:36 PM, Cyd Haselton <chaselton@xxxxxxxxx> wrote:

On Oct 27, 2013 6:36 PM, "Cyd Haselton" <chaselton@xxxxxxxxx> wrote:
>
> Android apparently doesn't support implicit conversion so had to do a
> cast before the argument is passed.
>
> I added
>
> off_t ot = (off_t) &file->st.st_size;
>
> before _cpp_convert_input, and passed &ot to argument 7 in _cpp_convert_input.
>

UPDATE: The above modification allowed the build to complete but results in a
bad address error when resulting binaries are run on device.
Will revise and try again...and email gcc-bugs if necessary.

> On Fri, Oct 25, 2013 at 12:34 PM, Cyd Haselton <chaselton@xxxxxxxxx> wrote:
>> Thanks to Ian's suggestion, I was able to push past the conversion
>> error with macro.c.  Unfortunately  two more problems have surfaced.
>>
>> The first happened after "fixing" the macro.c issue; the build
>> continued but then threw a number of undefined errors for functions
>> contained in libcpp when trying to build part of the cc1 binary.  I
>> don't have the exact functions; I'll post them if they show up again.
>>
>> Since I'd been making some changes to internal.h and files.c in the
>> interim source directory, I ran make distclean in the build directory,
>> copied the original files over to the interim source, and re-ran
>> configure.
>>
>> The second error appears after the above; make fails after the following error
>>
>> ../../gcc-4.8/libcpp/files.c: In fuction 'bool
>> read_file_guts(cpp_reader*, _cpp_file*)':
>> ../../gcc-4.8/lilbcpp/files/c:723:27: error:  cannot convert 'long
>> long int*' to 'off_t* {aka long int*}' for argument '7' to 'unsigned
>> char* _cpp_convert_input(cpp_reader*, const char*, unsigned char*,
>> size_t, size_t, const unsigned char**, off_t*)'
>>
>> I've done some research on this error while trying to resolve this;
>> for Android, off_t is always 32bits and there is an off64_t, but I
>> don't know if the error I'm getting above is because of this fact or
>> something related to the problem I was having with macro.c.
>>
>> Any help is appreciated.




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux