All of lore.kernel.org
 help / color / mirror / Atom feed
* #yocto cmake configurations
@ 2021-05-02 17:28 Monsees, Steven C (US)
  2021-05-04 18:23 ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-02 17:28 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]


I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve

[-- Attachment #2: Type: text/html, Size: 2651 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: #yocto cmake configurations
  2021-05-02 17:28 #yocto cmake configurations Monsees, Steven C (US)
@ 2021-05-04 18:23 ` Monsees, Steven C (US)
  2021-05-04 18:35   ` [yocto] " Khem Raj
  0 siblings, 1 reply; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-04 18:23 UTC (permalink / raw)
  To: Monsees, Steven C (US), yocto

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]


My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld…

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of –L’s…

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.



I am using zeus, standard SDK, cmake…

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve

[-- Attachment #2: Type: text/html, Size: 8824 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 18:23 ` Monsees, Steven C (US)
@ 2021-05-04 18:35   ` Khem Raj
  2021-05-04 19:56     ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2021-05-04 18:35 UTC (permalink / raw)
  To: Monsees, Steven C (US); +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 3292 bytes --]

can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via
lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org>
wrote:

>
>
> My standard zeus SDK appears to have an issue linking in my applications
> dynamic libs…
>
>
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm_intel
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -lclang
>
> collect2: error: ld returned 1 exit status
>
> The libraries are under:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/
>
>
>
> My CMake build app does not appear to have an issue finding the files:
>
>
>
>
> DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
>
>
> DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so
>
>
>
> It appears to be an issue specifically with the ld…
>
>
>
> LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT}
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread
> -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
>
>
>
> It does not appear to be making use of –L’s…
>
>
>
> Is there something I might look at/configure (i.e. add paths to search
> paths) ?
>
> Is there a simple test to validate tool ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Sunday, May 2, 2021 1:28 PM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> I am using zeus, standard SDK, cmake…
>
>
>
> Can I pre-configure the SDK to setup cmake package search paths ?, say for
> find_package, etc. (i.e. detecting external libraries/programs)…
>
>
>
> The majority of my env is configuring properly, but I am finding cmake is
> setup for a standard linux env with regards to these types of searches, and
>
> I wanted the cmake built in to look at my SDK paths (first by default)
> when doing such things as detecting python interpreter, libraries, etc.
>
>
>
> I am working on third party package unaware of my SDK setup.
>
>
>
> Thanks,
>
> Steve
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 8019 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 18:35   ` [yocto] " Khem Raj
@ 2021-05-04 19:56     ` Monsees, Steven C (US)
  2021-05-04 21:17       ` Khem Raj
  0 siblings, 1 reply; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-04 19:56 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto


[-- Attachment #1.1: Type: text/plain, Size: 3860 bytes --]


Attached...

From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve



[-- Attachment #1.2: Type: text/html, Size: 14602 bytes --]

[-- Attachment #2: link.txt --]
[-- Type: text/plain, Size: 7009 bytes --]

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++  --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types   -funroll-loops -fstrict-aliasing -msse2 -msse3 -mssse3 -msse4.1 -fPIC -Wall -mfpmath=sse -Wcast-align  -std=c++0x -Wno-invalid-offsetof -fno-rtti -I/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DGBE_DEBUG_MEMORY=0  -DGBE_COMPILER_AVAILABLE=1 -fvisibility=hidden -O0 -g -DGBE_DEBUG=1  --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -static CMakeFiles/gbe_bin_generater.dir/gbe_bin_generater.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/intrusive_list.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/assert.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/alloc.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/mutex.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/platform.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/cvar.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/context.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/profile.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/type.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/unit.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/constant.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/sampler.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/image.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/half.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/instruction.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/liveness.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/register.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/function.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/value.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/lowering.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/profiling.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/printf.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/immediate.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/structurizer.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/reloc.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/program.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_sampler_fix.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_bitcode_link.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_gen_backend.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_passes.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_scalarize.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_intrinsic_lowering.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_barrier_nodup.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_printf_parser.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_profiling.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandConstantExpr.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandUtils.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/PromoteIntegers.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandLargeIntegers.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_device_enqueue.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/StripAttributes.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_to_gen.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_loadstore_optimization.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_unroll.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen/gen_mesa_disasm.c.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection_optimize.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_scheduling.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection_output.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_reg_allocation.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen75_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen8_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen9_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_program.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_compact.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen7_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen75_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen8_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen9_encoder.cpp.o  -o gbe_bin_generater -ldrm_intel -ldrm -lclang -Wl,-Bstatic -lclangAnalysis -lclangARCMigrate -lclangAST -lclangASTMatchers -lclangBasic -lclangCodeGen -lclangCrossTU -lclangDriver -lclangDynamicASTMatchers -lclangEdit -lclangFormat -lclangFrontend -lclangFrontendTool -lclangHandleCXX -lclangIndex -lclangLex -lclangParse -lclangRewrite -lclangRewriteFrontend -lclangSema -lclangSerialization -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTooling -Wl,-Bdynamic -lLLVMXRay -lLLVMWindowsManifest -lLLVMTextAPI -lLLVMTableGen -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMOrcJIT -lLLVMJITLink -lLLVMObjectYAML -lLLVMMCA -lLLVMLTO -lLLVMPasses -lLLVMObjCARCOpts -lLLVMLineEditor -lLLVMLibDriver -lLLVMInterpreter -lLLVMFuzzMutate -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMDlltoolDriver -lLLVMOption -lLLVMDebugInfoGSYM -lLLVMCoverage -lLLVMCoroutines -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Utils -lLLVMX86Info -lLLVMRISCVDisassembler -lLLVMRISCVCodeGen -lLLVMRISCVAsmParser -lLLVMRISCVDesc -lLLVMRISCVUtils -lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMBPFDisassembler -lLLVMBPFCodeGen -lLLVMBPFAsmParser -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Utils -lLLVMAArch64Info -lLLVMAMDGPUDisassembler -lLLVMMCDisassembler -lLLVMAMDGPUCodeGen -lLLVMMIRParser -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMDebugInfoDWARF -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMBitReader -lLLVMBitstreamReader -lLLVMAMDGPUAsmParser -lLLVMMCParser -lLLVMAMDGPUDesc -lLLVMAMDGPUUtils -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCore -lLLVMRemarks -lLLVMBinaryFormat -lLLVMAMDGPUInfo -lLLVMSupport -lLLVMDemangle -lz -lrt -ldl -lpthread -lm -lxml2 -ldl 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 19:56     ` Monsees, Steven C (US)
@ 2021-05-04 21:17       ` Khem Raj
  2021-05-04 22:18         ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2021-05-04 21:17 UTC (permalink / raw)
  To: Monsees, Steven C (US); +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]

I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via
lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org>
wrote:

>
>
> Attached…
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 2:36 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> can you post full linker cmd which is failing ?
>
>
>
> On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> My standard zeus SDK appears to have an issue linking in my applications
> dynamic libs…
>
>
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm_intel
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -lclang
>
> collect2: error: ld returned 1 exit status
>
> The libraries are under:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/
>
>
>
> My CMake build app does not appear to have an issue finding the files:
>
>
>
>
> DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
>
>
> DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so
>
>
>
> It appears to be an issue specifically with the ld…
>
>
>
> LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT}
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread
> -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
>
>
>
> It does not appear to be making use of –L’s…
>
>
>
> Is there something I might look at/configure (i.e. add paths to search
> paths) ?
>
> Is there a simple test to validate tool ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Sunday, May 2, 2021 1:28 PM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> I am using zeus, standard SDK, cmake…
>
>
>
> Can I pre-configure the SDK to setup cmake package search paths ?, say for
> find_package, etc. (i.e. detecting external libraries/programs)…
>
>
>
> The majority of my env is configuring properly, but I am finding cmake is
> setup for a standard linux env with regards to these types of searches, and
>
> I wanted the cmake built in to look at my SDK paths (first by default)
> when doing such things as detecting python interpreter, libraries, etc.
>
>
>
> I am working on third party package unaware of my SDK setup.
>
>
>
> Thanks,
>
> Steve
>
>
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 11651 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 21:17       ` Khem Raj
@ 2021-05-04 22:18         ` Monsees, Steven C (US)
  2021-05-04 23:45           ` Khem Raj
  0 siblings, 1 reply; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-04 22:18 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 4941 bytes --]

Yes, LLVM & Clang...

From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

Attached...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve




[-- Attachment #2: Type: text/html, Size: 18999 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 22:18         ` Monsees, Steven C (US)
@ 2021-05-04 23:45           ` Khem Raj
  2021-05-05 10:44             ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2021-05-04 23:45 UTC (permalink / raw)
  To: Monsees, Steven C (US); +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 5337 bytes --]

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot
if you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via
lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org>
wrote:

> Yes, LLVM & Clang…
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 5:17 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> I see its using -rdynamic -static
>
> so next question is that do you have .a files in your sdk ?
>
>
>
> On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> Attached…
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 2:36 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> can you post full linker cmd which is failing ?
>
>
>
> On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> My standard zeus SDK appears to have an issue linking in my applications
> dynamic libs…
>
>
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm_intel
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -lclang
>
> collect2: error: ld returned 1 exit status
>
> The libraries are under:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/
>
>
>
> My CMake build app does not appear to have an issue finding the files:
>
>
>
>
> DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
>
>
> DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so
>
>
>
> It appears to be an issue specifically with the ld…
>
>
>
> LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT}
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread
> -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
>
>
>
> It does not appear to be making use of –L’s…
>
>
>
> Is there something I might look at/configure (i.e. add paths to search
> paths) ?
>
> Is there a simple test to validate tool ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Sunday, May 2, 2021 1:28 PM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> I am using zeus, standard SDK, cmake…
>
>
>
> Can I pre-configure the SDK to setup cmake package search paths ?, say for
> find_package, etc. (i.e. detecting external libraries/programs)…
>
>
>
> The majority of my env is configuring properly, but I am finding cmake is
> setup for a standard linux env with regards to these types of searches, and
>
> I wanted the cmake built in to look at my SDK paths (first by default)
> when doing such things as detecting python interpreter, libraries, etc.
>
>
>
> I am working on third party package unaware of my SDK setup.
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 15117 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-04 23:45           ` Khem Raj
@ 2021-05-05 10:44             ` Monsees, Steven C (US)
  2021-05-05 11:25               ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-05 10:44 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 6365 bytes --]


Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

Steve

From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:
Yes, LLVM & Clang...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

Attached...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve





[-- Attachment #2: Type: text/html, Size: 25583 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-05 10:44             ` Monsees, Steven C (US)
@ 2021-05-05 11:25               ` Monsees, Steven C (US)
  0 siblings, 0 replies; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-05 11:25 UTC (permalink / raw)
  To: Monsees, Steven C (US), Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 7550 bytes --]


All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue...

Steve

From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

Steve

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:
Yes, LLVM & Clang...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

Attached...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve




[-- Attachment #2: Type: text/html, Size: 29764 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
  2021-05-05 21:06   ` Khem Raj
@ 2021-05-06 12:26     ` Monsees, Steven C (US)
  0 siblings, 0 replies; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-06 12:26 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 16976 bytes --]


Thanks… I forgot that… linked.

I appreciate the help.
Steve

From: Khem Raj <raj.khem@gmail.com>
Sent: Wednesday, May 5, 2021 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>> wrote:

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

The link command is attached as “tmp.txt”.

There are a lot of these being generated, this is but a subset…
Note:
(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?
                (2) the code with the undefined reference does appear to be missing the proper header file reference



/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'


From: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>; Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: RE: [yocto] #yocto cmake configurations


All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.



Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

Steve

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:
Yes, LLVM & Clang…

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

Attached…

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld…

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of –L’s…

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.



I am using zeus, standard SDK, cmake…

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve




[-- Attachment #2: Type: text/html, Size: 52216 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
       [not found] ` <6092f7bc.1c69fb81.17f98.3a7cSMTPIN_ADDED_MISSING@mx.google.com>
@ 2021-05-05 21:06   ` Khem Raj
  2021-05-06 12:26     ` Monsees, Steven C (US)
  0 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2021-05-05 21:06 UTC (permalink / raw)
  To: Monsees, Steven C (US); +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 16390 bytes --]

usually one uses llvm-config to get the libs and order is important too
especially with static libs. Can you dump all .a files from clang and see
if its defined in some other .a which is either missing or present
after the faulting .a in linker cmd

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <
steven.monsees@baesystems.com> wrote:

>
>
> I made some modification in the cmake modules to adjust for the linker
> issue below, but now I appear to have uncovered an issue with the static
> libraries which meta-clang generated under the SDK… (see below)…
>
>
>
> The link command is attached as “tmp.txt”.
>
>
>
> There are a lot of these being generated, this is but a subset…
>
> Note:
>
> (1) “workspace_3” is a reference to my build area where I built the STD
> SDK, why would this be here the SDK should be independent of this are, no ?
>
>                 (2) the code with the undefined reference does appear to
> be missing the proper header file reference
>
>
>
>
>
>
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `CodeGenModule':
>
> */disk0/scratch/smonsees/yocto/**workspace_3*
> */builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib*/CodeGen/CodeGenModule.cpp:114:
> undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116:
> undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118:
> undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543:
> undefined reference to `clang::Decl::getAttrs() const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `clang::CodeGen::CodeGenModule::checkAliases()':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304:
> undefined reference to `clang::Decl::getDefiningAttr() const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>()
> const':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539:
> undefined reference to `clang::Decl::getAttrs() const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543:
> undefined reference to `clang::Decl::getAttrs() const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `clang::CodeGen::CodeGenModule::Release()':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520:
> undefined reference to
> `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788:
> undefined reference to
> `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl
> const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819:
> undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function
> `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
> undefined reference to
> `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*)
> const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
> undefined reference to
> `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*)
> const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
> undefined reference to
> `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*)
> const'
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
> in function `clang::Module::getTopLevelModuleName() const':
>
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468:
> undefined reference to `clang::Module::getTopLevelModule() const'
>
>
>
>
>
> *From:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Sent:* Wednesday, May 5, 2021 7:25 AM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>; Khem Raj <
> raj.khem@gmail.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* RE: [yocto] #yocto cmake configurations
>
>
>
>
>
> All the libraries are under the SDK here:
>
>
>
>
> -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib
>
>
>
> I need the DRM libraries to be picked up correctly, libclang.so may not be
> required since I have all the static variations available, (added to while
> testing linker) I have yet to make it through entire build due to linker
> issue…
>
>
>
> Steve
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Wednesday, May 5, 2021 6:44 AM
> *To:* Khem Raj <raj.khem@gmail.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> Khem:
>
>
>
> I only have the following libraries present for these:
>
>
>
> libclang.so
>
> libclang.so.9
>
> libdrm_intel.so
>
> libdrm_intel.so.1
>
> libdrm_intel.so.1.0.0
>
> libdrm.so
>
> libdrm.so.2
>
> libdrm.so.2.4.0
>
>
>
> I do generate the static (*.a) files for both LLVM & Clang and they appear
> to all be present (No libclang.a was generated).
>
>
>
> Steve
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 7:46 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> the cmd seems to pass --sysroot correctly so can you search in SDK sysroot
> if you have libclang.a libdrm_intel.a and libdrm.a ?
>
>
>
> On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
> Yes, LLVM & Clang…
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 5:17 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> I see its using -rdynamic -static
>
> so next question is that do you have .a files in your sdk ?
>
>
>
> On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> Attached…
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Tuesday, May 4, 2021 2:36 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> can you post full linker cmd which is failing ?
>
>
>
> On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> My standard zeus SDK appears to have an issue linking in my applications
> dynamic libs…
>
>
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm_intel
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -ldrm
>
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
> cannot find -lclang
>
> collect2: error: ld returned 1 exit status
>
> The libraries are under:
> /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/
>
>
>
> My CMake build app does not appear to have an issue finding the files:
>
>
>
>
> DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
>
>
> DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so
>
>
>
> It appears to be an issue specifically with the ld…
>
>
>
> LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT}
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib
> -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread
> -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
>
>
>
> It does not appear to be making use of –L’s…
>
>
>
> Is there something I might look at/configure (i.e. add paths to search
> paths) ?
>
> Is there a simple test to validate tool ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Sunday, May 2, 2021 1:28 PM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* [yocto] #yocto cmake configurations
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> I am using zeus, standard SDK, cmake…
>
>
>
> Can I pre-configure the SDK to setup cmake package search paths ?, say for
> find_package, etc. (i.e. detecting external libraries/programs)…
>
>
>
> The majority of my env is configuring properly, but I am finding cmake is
> setup for a standard linux env with regards to these types of searches, and
>
> I wanted the cmake built in to look at my SDK paths (first by default)
> when doing such things as detecting python interpreter, libraries, etc.
>
>
>
> I am working on third party package unaware of my SDK setup.
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 38984 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [yocto] #yocto cmake configurations
       [not found] <2f1f75947ea04d10ada871fb84cf6dac@baesystems.com>
@ 2021-05-05 19:53 ` Monsees, Steven C (US)
       [not found] ` <6092f7bc.1c69fb81.17f98.3a7cSMTPIN_ADDED_MISSING@mx.google.com>
  1 sibling, 0 replies; 12+ messages in thread
From: Monsees, Steven C (US) @ 2021-05-05 19:53 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto


[-- Attachment #1.1: Type: text/plain, Size: 15652 bytes --]


I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK... (see below)...

The link command is attached as "tmp.txt".

There are a lot of these being generated, this is but a subset...
Note:
(1) "workspace_3" is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?
                (2) the code with the undefined reference does appear to be missing the proper header file reference



/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'


From: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; Khem Raj <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto cmake configurations


All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue...

Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

Steve

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:
Yes, LLVM & Clang...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

Attached...

From: Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com<mailto:steven.monsees@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org> <steven.monsees=baesystems.com@lists.yoctoproject.org<mailto:baesystems.com@lists.yoctoproject.org>> wrote:

My standard zeus SDK appears to have an issue linking in my applications dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve




[-- Attachment #1.2: Type: text/html, Size: 44042 bytes --]

[-- Attachment #2: tmp.txt --]
[-- Type: text/plain, Size: 7650 bytes --]




disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++ --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux   --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types   -funroll-loops -fstrict-aliasing -msse2 -msse3 -mssse3 -msse4.1 -fPIC -Wall -mfpmath=sse -Wcast-align  -std=c++0x -Wno-invalid-offsetof -fno-rtti -I/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/include -I/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/include/clang -I/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/include/llvm -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DGBE_DEBUG_MEMORY=0  -DGBE_COMPILER_AVAILABLE=1 -fvisibility=hidden -O0 -g -DGBE_DEBUG=1  --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed --sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib -L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -static CMakeFiles/gbe_bin_generater.dir/gbe_bin_generater.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/intrusive_list.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/assert.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/alloc.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/mutex.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/platform.cpp.o CMakeFiles/gbe_bin_generater.dir/sys/cvar.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/context.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/profile.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/type.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/unit.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/constant.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/sampler.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/image.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/half.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/instruction.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/liveness.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/register.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/function.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/value.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/lowering.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/profiling.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/printf.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/immediate.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/structurizer.cpp.o CMakeFiles/gbe_bin_generater.dir/ir/reloc.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/program.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_sampler_fix.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_bitcode_link.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_gen_backend.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_passes.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_scalarize.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_intrinsic_lowering.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_barrier_nodup.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_printf_parser.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_profiling.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandConstantExpr.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandUtils.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/PromoteIntegers.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/ExpandLargeIntegers.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_device_enqueue.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/StripAttributes.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_to_gen.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_loadstore_optimization.cpp.o CMakeFiles/gbe_bin_generater.dir/llvm/llvm_unroll.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen/gen_mesa_disasm.c.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection_optimize.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_scheduling.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_selection_output.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_reg_allocation.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen75_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen8_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen9_context.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_program.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_insn_compact.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen7_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen75_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen8_encoder.cpp.o CMakeFiles/gbe_bin_generater.dir/backend/gen9_encoder.cpp.o  -o gbe_bin_generater -Wl,-Bstatic -lclangAnalysis -lclangARCMigrate -lclangAST -lclangASTMatchers -lclangBasic -lclangCodeGen -lclangCrossTU -lclangDriver -lclangDynamicASTMatchers -lclangEdit -lclangFormat -lclangFrontend -lclangFrontendTool -lclangHandleCXX -lclangIndex -lclangLex -lclangParse -lclangRewrite -lclangRewriteFrontend -lclangSema -lclangSerialization -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTooling -Wl,-Bdynamic -lLLVMXRay -lLLVMWindowsManifest -lLLVMTextAPI -lLLVMTableGen -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMOrcJIT -lLLVMJITLink -lLLVMObjectYAML -lLLVMMCA -lLLVMLTO -lLLVMPasses -lLLVMObjCARCOpts -lLLVMLineEditor -lLLVMLibDriver -lLLVMInterpreter -lLLVMFuzzMutate -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMDlltoolDriver -lLLVMOption -lLLVMDebugInfoGSYM -lLLVMCoverage -lLLVMCoroutines -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Utils -lLLVMX86Info -lLLVMRISCVDisassembler -lLLVMRISCVCodeGen -lLLVMRISCVAsmParser -lLLVMRISCVDesc -lLLVMRISCVUtils -lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMBPFDisassembler -lLLVMBPFCodeGen -lLLVMBPFAsmParser -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Utils -lLLVMAArch64Info -lLLVMAMDGPUDisassembler -lLLVMMCDisassembler -lLLVMAMDGPUCodeGen -lLLVMMIRParser -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMDebugInfoDWARF -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMBitReader -lLLVMBitstreamReader -lLLVMAMDGPUAsmParser -lLLVMMCParser -lLLVMAMDGPUDesc -lLLVMAMDGPUUtils -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCore -lLLVMRemarks -lLLVMBinaryFormat -lLLVMAMDGPUInfo -lLLVMSupport -lLLVMDemangle -lz -lrt -ldl -lpthread -lm -lxml2 -ldrm_intel -ldrm -ldl



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-05-06 12:26 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-02 17:28 #yocto cmake configurations Monsees, Steven C (US)
2021-05-04 18:23 ` Monsees, Steven C (US)
2021-05-04 18:35   ` [yocto] " Khem Raj
2021-05-04 19:56     ` Monsees, Steven C (US)
2021-05-04 21:17       ` Khem Raj
2021-05-04 22:18         ` Monsees, Steven C (US)
2021-05-04 23:45           ` Khem Raj
2021-05-05 10:44             ` Monsees, Steven C (US)
2021-05-05 11:25               ` Monsees, Steven C (US)
     [not found] <2f1f75947ea04d10ada871fb84cf6dac@baesystems.com>
2021-05-05 19:53 ` Monsees, Steven C (US)
     [not found] ` <6092f7bc.1c69fb81.17f98.3a7cSMTPIN_ADDED_MISSING@mx.google.com>
2021-05-05 21:06   ` Khem Raj
2021-05-06 12:26     ` Monsees, Steven C (US)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.