-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Having trouble in building with cross-compiler #532
Comments
@jongwonjlee I'm also interested in the portability of BLIS on embedded platforms. Can you share the error of Then, I believe "Cannot determine operating system" is a preprocessing error (https://github.com/flame/blis/blob/master/frame/include/bli_system.h#L94), while you mentioned a link issue ? |
@hominhquan It states as follows when linked to the tutorial code:
For the second question, yes it seems to be a preprocessing error when making the BLIS library file. Doesn't it have to do with configuring for the target processor? |
On the linking issue, it looks like your compiler toolchain does not provide any On the preprocessing error "Cannot determine operating system", yes, one who wants to port BLIS on a new architecture (as well as new OS) needs adding associated macros in
Good luck. |
@hominhquan Oh, the target processor's OS (FreeRTOS) is classified into none of them in the list that BLIS is supposed to support. Does it mean that I can't use BLIS for the target environment? |
BLIS has been written as much portable as possible. Any compiler supporting C99 can compile BLIS mostly out-of-the-box. Any new architecture not figuring in the OS list can still be cross-compiled after some code modification (points mentioned above). That can be some more tricky, but is not impossible either. Then you can create PR to contribute to BLIS. I think @fgvanzee, @rvdg and @devinamatthews will be more than happy to see BLIS ported on new architectures. |
@jongwonjlee I've added a checklist to the Issue description to try and break down the different sub-issues, then we can work down the list one at a time. |
Re
|
Re |
FYI, it definitely seems that you'll need to create your own configuration, whether or not you eventually want to write optimized microkernels or not. Please see here for instructions. |
OS macros except Windows and OSX cause no problem while running
|
@devinamatthews Thanks for your comments. I am stilling with fprintf implicit declaration error and cannot figure out how to resolve this issue. Why do you think the error occurs though the EWL library supports FYI, I attached the log file while doing |
@jongwonjlee please attach the file |
BTW, can you also send the output of |
@jongwonjlee shouldn't you have to explicitly link some library or libraries with |
@devinamatthews Thanks for your suggestion. Enforcing the macro required for EWL's
BTW, it faced warnings as stated below. Do you think this may result in a significant problem later on? (I attach the log while executing
|
@devinamatthews FYI, I attach the resultant zip file by running the configuration causing no error while making.
|
@devinamatthews For another FYI, I also attach macros for the cross compiler I'm using. |
This is fine. |
There's not really any pre-defined macro in that list that gives an idea what OS it is/will be running on. @fgvanzee for builds with |
@jongwonjlee re the flags for EWL, based on the GCC docs I think all you need is |
If you think this will help, we can do this. |
@jongwonjlee my understanding is that you initially got the error "Cannot determine operating system"? @fgvanzee if so then yes this is needed for @jongwonjlee's configuration to work properly without masquerading as HURD which seem dangerous. |
Details: - Modified bli_system.h so that the cpp macro BLIS_OS_NONE is defined when BLIS_DISABLE_SYSTEM is defined. Otherwise, the previous OS- detecting macro conditionals are considered. This change is to accommodate a solution to a cross-compilation issue described in #532.
@devinamatthews Take a look at my modifications to |
Are you sure |
Oh, maybe I need to re-express the conditional in terms of |
So, turns out that's fine. This is from #if @enable_system@
#define BLIS_ENABLE_SYSTEM
#else
#define BLIS_DISABLE_SYSTEM
#endif |
BTW, I've temporarily disabled the changes in 8e0c425, so we're back to passing on AppVeyor. |
@devinamatthews That was the case. As the
However, the problem is, when I try to go through the tutorial codes (i.e. examples in My question is, is this a strong red flag that hampers me from move forward? In other words, I am just wondering if this will require a lot of additional trials errors. What is your opinion on this? Otherwise, it is also welcomed if you can point out any suspicious points to be investigated. |
…stem mode - Before, OS-detection is always done even with --disable-system, because bli_system.h is included before bli_config.h. This may explain why 8e0c425 has been reverted in 2be78fc. - This commit swaps their order (/!\) : bli_config.h before bli_system.h. - Also better support future non-system platforms (flame#532)
Details: - Re-enable the changes originally made in 8e0c425 but quickly reverted in 2be78fc. - Moved the #include of bli_config.h so that it occurs before the #include of bli_system.h. This allows the #define BLIS_ENABLE_SYSTEM or #define BLIS_DISABLE_SYSTEM in bli_config.h to be processed by the time it is needed in bli_system.h. This change should have been in the original 8e0c425, but was accidentally omitted. Thanks to Minh Quan Ho for catching this. - Add #define BLIS_ENABLE_SYSTEM to config_detect.c so that the proper cpp conditional branch executes in bli_system.h when compiling the hardware detection binary. The changes made in 8e0c425 were an attempt to support the definition of BLIS_OS_NONE when configuring with --disable-system (in issue #532). That commit failed because, aside from the required but omitted header reordering (second bullet above), AppVeyor was unable to compile the hardware detection binary as a result of missing Windows headers. This commit, which builds on PR #546, should help fix that issue. Thanks to Minh Quan Ho for his assistance and patience on this matter.
Details: - Re-enabled the changes made in fb93d24. - Defined BLIS_ENABLE_SYSTEM in bli_arch.c, bli_cpuid.c, and bli_env.c, all of which needed the definition (in addition to config_detect.c) in order for the configure-time hardware detection binary to be compiled properly. Thanks to Minh Quan Ho for helping identify these additional files as needing to be updated. - Added additional comments to all four source files, most notably to prompt the reader to remember to update all of the files when updating any of the files. Also made the cpp code in each of the files as consistent/similar as possible. - Refer to issues #532 and PR #546 for more history.
Hi, I appreciate your hard work! I'm now trying to create BLIS static library for a target microcontroller (NXP MPC5748G, having 32bit PowerPC architecture on which code built by GCC is mounted) through the corresponding cross compiler with its specialized C standard library called EWL, but I'm in trouble while building the code.
Prerequisite:
What I tried was:
config/generic/
and populatemake_defs.mk
with details / flags on the target cross compiler. (I attach themake_defs.mk
file I used.)./configure CC=${HOME}/NXP/S32DS_Power_v2.1/S32DS/build_tools/powerpc-eabivle-4_9/bin/powerpc-eabivle-gcc --disable-shared --disable-threading --disable-system --enable-verbose-make generic
to genrate Makefile.make -j
encounters "Cannot determine operating system" error, I go intoinclude/generic/blis.h
file, comment two blocks causing the error, and explicitly define#define BLIS_OS_GNU 1
(I attach the modified header file I used.)make -j
, but it shows warning statements pertaining to usingfprintf
. (I attach the build logs (containing standard statements and warnings separately) as well.)Anyway, it ends up creating the static library file
libblis.a
. But when I try to link it with the BLIS tutorial code, it throws similar errors as mentioned above; this is not so surprising as the library file has been built 'incomplete'.As the
system root
(where the standard C libraries are located) has been set properly to be${HOME}/NXP/S32DS_Power_v2.1/S32DS/build_tools/e200_ewl2/' and
stdio` is in there, I believe that it wouldn't cause such issues but it didn't. This problem has eaten up to much time and effort so far. It would be really appreciated if anyone knows a silver bullet to get around such an issue. Otherwise, it would be also great if somebody can suggest a possible direction I should take. Thanks in advance!files mentioned above
files.zip
Checklist (with documentation of solutions):
BLIS_OS_NONE
?system_root
/flags for EWLfprintf
The text was updated successfully, but these errors were encountered: