search

gavinhoward / bc

An implementation of the POSIX bc calculator with GNU extensions and dc, moved away from GitHub. Finished, but well-maintained.
https://git.gavinhoward.com/gavin/bc
Other
145 stars 29 forks source link

Specifying `--prefix` when cross-compiling #56

Closed firasuke closed 1 year ago

firasuke commented 1 year ago

Hey there,

I've encountered an error recently where attempting to cross-compile bc while using CC as the cross compiler and HOSTCC as the compiler and when passing --prefix=/usr as a configuration flag.

It appears that bc is searching for header files in $PREFIX/include, although the help message mentions that these options control the installation directories of bc files and not the directories header/library files are searched for.

The error disappears when I remove the --prefix=/usr flag and the installation defaults to /usr/local as there's no way to change it because --prefix causes an error.

The error is:

     /usr/include/bits/types/time_t.h:8:9: error: unknown type name '__time64_t'
    8 | typedef __time64_t time_t;
      |         ^~~~~~~~~~

I don't recall changing the configuration flags I use for bc since version 4.0, did the behavior of these flags change?

Thanks in advance!

gavinhoward commented 1 year ago

This looks like a bug in configure.sh. However, I need to know now to track it down.

Can you tell me what the host system is, what the target system is, what the host compiler is, and what the target compiler is?

firasuke commented 1 year ago

The host system architecture tuple is x86_64-unknown-linux-gnu and the target architecture tuple is x86_64-linux-musl.

The host compiler HOSTCC=gcc and the target compiler is CC=x86_64-linux-musl-gcc.

firasuke commented 1 year ago

I thought this will might help narrow down the cause.

The last known working version that I tried using the same configuration flags and recipe file is version 5.2.5, so my guess would be that the change happened after that release, possibly with the latest 6.0 release.

firasuke commented 1 year ago

I think I found the faulty commit.

gavinhoward commented 1 year ago

I think you did too.

That commit appears to have been made as exploration; I should have added more to the commit message. Nevertheless, it appears to not be necessary anymore because I tested the FreeBSD port without those changes, and it worked fine.

So I committed 2b65eb21cfc575fdb04a090c687bd102a80cc43c to erase the rest of that commit. Can you pull and test it?

firasuke commented 1 year ago

I can confirm that this indeed 2b65eb21cfc575fdb04a090c687bd102a80cc43c fixed the issue.

Can you release this fix in a new bugfix version?

gavinhoward commented 1 year ago

Wonderful!

I'll release a bug fix version as soon as I have confirmation that this fix does not break FreeBSD. I hope that will be soon.

gavinhoward commented 1 year ago

Release 6.0.3 is out. I hope it fixes your issue.

If it doesn't, please feel free to reopen.

firasuke commented 1 year ago

Yup, the new release solved the issue.

Thanks for your time and effort!