Bug 105852 - Fix cmake call for openemebedded builds (and Fedora)
Summary: Fix cmake call for openemebedded builds (and Fedora)
Status: RESOLVED MOVED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-02 19:19 UTC by Andreas Müller
Modified: 2018-08-21 10:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch (3.09 KB, patch)
2018-04-02 19:19 UTC, Andreas Müller
Details | Splinter Review
Patch with description rewritten (3.12 KB, patch)
2018-04-03 09:34 UTC, Andreas Müller
Details | Splinter Review

Description Andreas Müller 2018-04-02 19:19:19 UTC
Created attachment 138506 [details] [review]
Patch

Overwriting CMAKE_CXX_FLAGS/CMAKE_C_FLAGS breaks openemebedded/yocto build and it seems Fedora needs a workaround too.
Comment 1 Albert Astals Cid 2018-04-02 21:27:17 UTC
I don't see how this would help since we're appending _save_cxxflags to add the supported build types.

Are you building with an unsupported CMAKE_BUILD_TYPE ?
Comment 2 Andreas Müller 2018-04-02 22:43:52 UTC
On Mon, Apr 2, 2018 at 11:27 PM,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 1 on bug 105852 from Albert Astals Cid
>
> I don't see how this would help since we're appending _save_cxxflags to add
> the
> supported build types.
>
> Are you building with an unsupported CMAKE_BUILD_TYPE ?
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.
I do not set CMAKE_BUILD_TYPE (like Fedora).
Comment 3 Andreas Müller 2018-04-03 09:34:11 UTC
Created attachment 138512 [details] [review]
Patch with description rewritten
Comment 4 Albert Astals Cid 2018-04-03 10:16:46 UTC
If you put an empty build type, it'll use RelWithDebInfo as per line 98 of that same file, so i still don't understand why you need the patch.

Are you or anything in your toolchain defining CMAKE_CONFIGURATION_TYPES ?
Comment 5 Andreas Müller 2018-04-03 11:34:33 UTC
Did not notice that and yes that is strange. Will look into but my take a bit...
Comment 6 Andreas Müller 2018-04-03 21:38:48 UTC
Ok - I cannot point where the magic happens that cmake moves CMAKE_CXX_FLAGS to test environment. I try by symptom:

In OE we have a toolchain.cmake file setting e.g
CMAKE_CXX_FLAGS " -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7  --sysroot=/<path> ... <much more>

Same for CMAKE_C_FLAGS

By overwriting CMAKE_C(XX)_FLAGS all these settings are kicked out so cmake does not know which arch it shall build for, where to find headers...

If you look at the log I added to patch: it is breaking at the very first checks because all required information is missing:
| -- Looking for pthread.h
| -- Looking for pthread.h - not found
| -- Could NOT find Threads (missing: Threads_FOUND)
| -- Check if the system is big endian
| -- Searching 16 bit integer
| -- Looking for sys/types.h
| -- Looking for sys/types.h - not found
| -- Looking for stdint.h
| -- Looking for stdint.h - not found
| -- Looking for stddef.h
| -- Looking for stddef.h - not found
| -- Check size of unsigned short
| -- Check size of unsigned short - failed
| -- Check size of unsigned int
| -- Check size of unsigned int - failed
| -- Check size of unsigned long
| -- Check size of unsigned long - failed
| CMake Error at /home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-angstrom-linux-gnueabi/poppler/0.62.0-r0/recipe-sysroot-native/usr/share/cmake-3.10/Modules/TestBigEndian.cmake:49 (message):
|   no suitable type found
| Call Stack (most recent call first):
|   CMakeLists.txt:21 (test_big_endian)

With the patch suggested sequence looks sane:
|-- Looking for pthread.h
|-- Looking for pthread.h - found
|-- Looking for pthread_create
|-- Looking for pthread_create - not found
|-- Check if compiler accepts -pthread
|-- Check if compiler accepts -pthread - yes
|-- Found Threads: TRUE  
|-- Check if the system is big endian
|-- Searching 16 bit integer
|-- Looking for sys/types.h
|-- Looking for sys/types.h - found
|-- Looking for stdint.h
|-- Looking for stdint.h - found
|-- Looking for stddef.h
|-- Looking for stddef.h - found
|-- Check size of unsigned short
|-- Check size of unsigned short - done
|-- Using unsigned short
|-- Check if the system is big endian - little endian
|-- Checking _FILE_OFFSET_BITS for large files
|-- Checking _FILE_OFFSET_BITS for large files - needed
Comment 7 Albert Astals Cid 2018-04-03 21:44:03 UTC
I never said the patch doesn't fix your problem, I'm just saying that before commiting something we need to understand why it fixes things, and if that is the correct fix or not.

In this case it seems we're not sure about that.
Comment 8 Andreas Müller 2018-04-03 22:57:42 UTC
Don't think it's only my problem - that's why I opened a bug here.

Looked into CMakeCache.txt (with patch applied / OE toolchain has NO entry for CMAKE_CXX_FLAGS_RELWITHDEBINFO) and find

CMAKE_CXX_FLAGS:STRING= -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7  --sysroot=<path> <...>

...
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

This is not much! That looks to me that CMake treats CMAKE_CXX_FLAGS_RELWITHDEBINFO as append of CMAKE_CXX_FLAGS. I think the whole flag dance is not designed as CMake expects it. It should be

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE")
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g")
set(CMAKE_CXX_FLAGS_RELEASE        "-O2 -DNDEBUG")
...

I tried to find hints on this on CMake docs but without success. End of the story.
Comment 9 GitLab Migration User 2018-08-21 10:47:14 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/373.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.