I am using OPROFILE to collect some performance data.
but I got in troubule.
Here is my shell:
~ # rm -f /root/.oprofile/daemonrc
~ # opcontrol --setup --no-vmlinux
~ # opcontrol --init
~ # opcontrol --reset
~ # opcontrol --start
~ # opcontrol --status
Daemon running: pid 14909
Separate options: none
vmlinux file: none
Image filter: none
Call-graph depth: 0
~ # opcontrol --shutdown
Stopping profiling.
Killing daemon.
~ # opreport
error: no sample files found: profile specification too strict?
~ # tree /var/lib/oprofile/
/var/lib/oprofile/
├── abi
├── complete_dump
├── jitdump
├── opd_pipe
└── samples
├── current
│ └── stats
│ ├── bt_lost_no_mapping
│ ├── cpu0
│ │ ├── backtrace_aborted
│ │ ├── sample_invalid_eip
│ │ ├── sample_lost_overflow
│ │ └── sample_received
│ ├── event_lost_overflow
│ ├── multiplex_counter
│ ├── sample_lost_no_mapping
│ └── sample_lost_no_mm
└── oprofiled.log
5 directories, 13 files
~ # dmesg |grep oprofile
oprofile: using NMI interrupt.
~ # uname -a
Linux localhost.localdomain 2.6.32-220.4.2.el6.x86_64 #1 SMP Tue Feb 14 04:00:16 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
~ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU E5620 # 2.40GHz
stepping : 2
cpu MHz : 2400.085
cache size : 12288 KB
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
bogomips : 4800.17
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Some CPU types do not provide the needed hardware support to use the hardware performance counters.
On these machines, OProfile falls back to using the timer interrupt for profiling, back to using the real-time clock interrupt to collect samples.
you can force use of the timer interrupt by using the timer=1 module parameter.If OProfile was built as a kernel module, then you must pass the 'timer=1' parameter with the modprobe command. Do this before executing 'opcontrol --init' or edit the opcontrol command's invocation of modprobe to pass the 'timer=1' parameter
modprobe oprofile timer=1
Then continue your profiling procedure
I ran into a similar problem on a RHEL6 based distribution. At some point, I started using perf with which I was able to get profiler reports and annotated source code.
Related
I have a toolchain from an older piece of hardware (W315 from Moxa), and when I run file on its library files, I get this:
[bf#localhost arm-linux-gnueabi]$ file /usr/local/arm-linux/lib/libssl.so.0.9.8
/usr/local/arm-linux/lib/libssl.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, not stripped
As you can see, this OpenSSL library is quite old and does not support TLSv1.2, which I need (at least). So I am trying to find an ARM binary of that library of a newer version. I have found 1.0.0 from Debian, but that has a little different signature:
[bf#localhost arm-linux-gnueabi]$ file libssl.so.1.0.0
libssl.so.1.0.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=83c83f5d3da36759c7adc837405b28539569d26e, stripped
They are both 32 bit, and ELF, but I am not sure if the "ARM" part is comparable.
Could I use that 1.0.0 library in my application? And if not, what should I look for in searching for the right binary?
Results from cat /proc/cpuinfo:
root#Moxa:/home/fabs# cat /proc/cpuinfo
Processor : ARM922Tid(wb) rev 1 (v4l)
BogoMIPS : 76.59
Features : swp half thumb
CPU implementer : 0x66
CPU architecture: 4
CPU variant : 0x0
CPU part : 0x526
CPU revision : 1
Cache type : VIVT write-back
Cache clean : cp15 c7 ops
Cache lockdown : format B
Cache format : Harvard
I size : 16384
I assoc : 2
I line length : 16
I sets : 512
D size : 16384
D assoc : 2
D line length : 16
D sets : 512
Hardware : Moxa CPU development platform
Revision : 0000
Serial : 0000000000000000
No, they are not. But You can build a recent/supported/secure version of openssl for your platform by using the following procedure:
# openssl
wget https://www.openssl.org/source/openssl-1.1.1k.tar.gz
tar zxf openssl-1.1.1k.tar.gz
# a toolchain I know is working for arm922t according to gcc documentation
wget "https://releases.linaro.org/components/toolchain/binaries/latest-6/arm-linux-gnueabi/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz" -O gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz
mkdir -p /opt/arm/6
tar Jxf gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi.tar.xz -C /opt/arm/6
# building
cd openssl-1.1.1k
./Configure linux-generic32 --cross-compile-prefix=/opt/arm/6/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi- --prefix=/opt/openssl-1.1.1k --openssldir=/opt/openssl-1.1.1k
Edit the Makefile, and replace
CFLAGS=-Wall -O3
by:
CFLAGS=-Wall -O3 -march=armv4t -mcpu=arm922t
Then:
make install
ls -gG /opt/openssl-1.1.1k/bin/
total 576
-rwxr-xr-x 1 6214 Jun 30 12:53 c_rehash
-rwxr-xr-x 1 579740 Jun 30 12:53 openssl
ls -gG /opt/openssl-1.1.1k/lib
total 6432
drwxr-xr-x 2 4096 Jun 30 12:53 engines-1.1
-rw-r--r-- 1 3312034 Jun 30 12:53 libcrypto.a
lrwxrwxrwx 1 16 Jun 30 12:53 libcrypto.so -> libcrypto.so.1.1
-rwxr-xr-x 1 2152072 Jun 30 12:53 libcrypto.so.1.1
-rw-r--r-- 1 603100 Jun 30 12:53 libssl.a
lrwxrwxrwx 1 13 Jun 30 12:53 libssl.so -> libssl.so.1.1
-rwxr-xr-x 1 502704 Jun 30 12:53 libssl.so.1
file /opt/openssl-1.1.1k/bin/openssl
/opt/openssl-1.1.1k/bin/openssl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=7b0e69c478f4c7390d416247f95ac60d9a632bd8, with debug_info, not stripped
If needed, you can build a static version by adding the -static option at the end of the configuration command:
./Configure linux-generic32 --cross-compile-prefix=/opt/arm/6/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi- --prefix=/opt/openssl-1.1.1k --openssldir=/opt/openssl-1.1.1k -static
I'm not sure if SO is the best place to ask this question but...
I've compiled my C program on, Linux Ubuntu (16.04), using
gcc -o MM1.x86 -O3 -static -mavx2 -g -Wall MM1.c
Running the file command
file MM1.x86
MM1.x86: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=078be440b466ba97bd4bf468b24eee35f8c6a01f, not stripped
But I've also cross compiled the same source file for ARM using
arm-linux-gnueabi-gcc -o MM1.ARM -O3 -static -g -Wall MM1.c
Running file
file MM1.ARM
MM1.ARM: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=b6582e1073682d41eb5262ad5393cebb8578e05d, not stripped
But after running the ARM compiled program, I was wondering how does it even run on x86_64 if it was compiled for ARM architecture?
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 60
Model name: Intel(R) Core(TM) i7-4790 CPU # 3.60GHz
Stepping: 3
CPU MHz: 886.640
CPU max MHz: 4000.0000
CPU min MHz: 800.0000
BogoMIPS: 7183.90
Virtualisation: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts
I did notice that the ARM version runs slightly slower, why is this so?
I'm trying to develop a new feature for an embedded application and I'd like to do so using a test-driven approach.
The project is written in pure C and is being developed using IAR Embedded Workbench 6.60.1.5104. I'm targeting an LPC1788, which is a Cortex-M3 device, and all development is being done on a 64-bit Windows 7 machine. Right now I'm more in favour of getting unit tests to run on the PC rather than on the target hardware (RAM is quite limited).
I came across a useful book on the subject called Test Driven Development for Embedded C and that pointed me towards tools like Unity, CppUTest, Ceedling, etc. After looking into this stuff, I think my best choice is to configure Ceedling (which uses Unity) for my project. However, I'm not sure exactly what steps I need to take to configure Ceedling to work with my current IAR toolchain.
I've installed Ceedling and created the "blinky" example project and I'm trying to build and test it using the IAR toolchain. I've added iccarm.exe to my path and edited blinky/project.yml as given below:
---
# Notes:
# This is a fully tested project that demonstrates the use
# of a timer ISR to blink the on board LED of an Arduino UNO
:project:
:use_exceptions: FALSE
:use_test_preprocessor: TRUE
:use_auxiliary_dependencies: TRUE
:build_root: build
:release_build: TRUE
:test_file_prefix: test_
#You'll have to specify these
:environment:
- :mcu: atmega328p
- :f_cpu: 16000000UL
- :serial_port: COM8 #change this to the serial port you are using!!!
- :objcopy: avr-objcopy
# Uncomment these lines if you are using windows and don't have these tools in your path
# - :path:
# - C:\mingw\bin
# - C:\WinAVR-20100110\bin
# - C:\WinAVR-20100110\utils\bin
# - #{ENV['PATH']}
:extension:
:executable: .bin
:release_build:
:output: blinky
:paths:
:test:
- +:test/**
- -:test/support
:source:
- src/**
:support:
- test/support
:defines:
# in order to add common defines:
# 1) remove the trailing [] from the :common: section
# 2) add entries to the :common: section (e.g. :test: has TEST defined)
:commmon: &common_defines []
:test:
- *common_defines
- TEST
:test_preprocess:
- *common_defines
- TEST
:tools:
:release_compiler:
:executable: avr-gcc
:arguments:
- ${1}
- -DTARGET
- -DF_CPU=#{ENV['F_CPU']}
- -mmcu=#{ENV['MCU']}
- -Iinclude/
- -Wall
- -Os
- -c
- -o ${2}
:release_linker:
:executable: avr-gcc
:arguments:
- -mmcu=#{ENV['MCU']}
- ${1}
- -o ${2}.bin
:cmock:
:mock_prefix: mock_
:when_no_prototypes: :warn
:enforce_strict_ordering: TRUE
:plugins:
- :ignore
:treat_as:
uint8: HEX8
uint16: HEX16
uint32: UINT32
int8: INT8
bool: UINT8
:tools:
:test_file_preprocessor:
:executable: iccarm
:name: 'IAR test file preprocessor'
:test_includes_preprocessor:
:executable: iccarm
:name: 'IAR test includes preprocessor'
:test_compiler:
:executable: iccarm
:name: 'IAR test compiler'
:test_linker:
:executable: iccarm
:name: 'IAR test linker'
:release_compiler:
:executable: iccarm
:name: 'IAR release compiler'
:release_linker:
:executable: iccarm
:name: 'IAR release linker'
:plugins:
:load_paths:
- vendor/ceedling/plugins
:enabled:
- stdout_pretty_tests_report
- module_generator
...
The only difference between this and the default project.yml is the content under the second :tools section.
My guess is that I'm heading in the right direction, but I'm not sure whether iccarm.exe is the correct executable to use for all these parts of the toolchain and what arguments I need to pass.
If I can configure Ceedling to build and test the blinky project using an IAR toolchain, I'm hoping I should be able to apply the same configuration for my actual project. If I try running rake now, I get the following output:
$ rake
Test 'test_BlinkTask.c'
-----------------------
rake aborted!
Errno::ENOENT: No such file or directory # rb_sysopen - build/test/preprocess/files/test_BlinkTask.c
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator_extractor.rb:18:in `readlines'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator_extractor.rb:18:in `extract_base_file_from_preprocessed_expansion'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator_file_handler.rb:14:in `preprocess_file'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator.rb:40:in `preprocess_file'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator.rb:12:in `block in setup'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator_helper.rb:33:in `preprocess_test_file'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/preprocessinator.rb:25:in `preprocess_test_and_invoke_test_mocks'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/test_invoker.rb:42:in `block in setup_and_invoke'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/test_invoker.rb:32:in `setup_and_invoke'
C:/Users/davidfallah/Documents/IAR Projects/blinky/vendor/ceedling/lib/ceedling/tasks_tests.rake:11:in `block (2 levels) in <top (required)>'
Tasks: TOP => default => test:all
(See full trace by running task with --trace)
--------------------
OVERALL TEST SUMMARY
--------------------
No tests executed.
I assume this is because the test file preprocessor should be copying test files under the build/test/preprocess/files directory, which currently doesn't happen.
After a bit of digging around I found this example configuration file for Unity that looks like it may be helpful. It's geared towards an IAR EW/Cortex M3 environment like the one I'm using. This may give some indication of what configuration options I need to specify in my Ceedling project.yml:
If I can get Ceedling to build and test the blinky project using an IAR toolchain, I'm hoping I can adapt it to work with my actual project. Any help would be appreciated.
It was a struggle but I believe I've managed to configure Ceedling to help test my project. Hopefully this will be useful to anyone else looking to use Ceedling within IAR projects.
The Ceedling CLI has a command (ceedling new <proj_name>) that allows you to create new projects with the structure Ceedling expects. You can also specify the name of an existing project in which case it only adds the necessary files to make it Ceedling-compatible, which is what I did with my project.
For reference, my project structure looked something like this after performing this step:
.
├── build
│ ├── artifacts
│ │ └── test
│ ├── docs
│ ├── exe
│ ├── list
│ ├── logs
│ ├── obj
│ ├── temp
│ └── test
│ ├── cache
│ ├── dependencies
│ ├── list.i
│ ├── mocks
│ ├── out
│ ├── results
│ ├── runners
│ └── tests.map
├── project.yml
├── rakefile.rb
├── src
│ └── main
│ ├── c
│ │ ├── canDatabase.c
│ ├── include
│ │ ├── canDatabase.h
│ ├── python
│ └── resources
├── test
│ ├── support
│ └── test_canDatabase.c
├── <my_project>.dep
├── <my_project>.ewd
├── <my_project>.ewp
├── <my_project>.eww
├── vendor
│ └── ceedling
│ ├── docs
│ ├── lib
│ ├── plugins
│ └── vendor
└── version.properties
After that, I looked over the reference manuals for the IAR tools and studied the output from IAR Embedded Workbench when building sample projects, as #user694733 suggested. I used this information to edit my project.yml as given below:
:project:
:use_exceptions: FALSE
:use_test_preprocessor: FALSE
:use_auxiliary_dependencies: TRUE
:build_root: build
:release_build: FALSE
:test_file_prefix: test_
:environment:
- :path:
- 'C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\bin'
- 'C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\common\bin'
- #{ENV['PATH']}
:extension:
:executable: .out
:paths:
:test:
- +:test/**
- -:test/support
:source:
- src/main/c/**
- src/main/include/**
- src/main/resources/**
:support:
- test/support
:defines:
:commmon: &common_defines []
:test:
- *common_defines
- TEST
:test_preprocess:
- *common_defines
- TEST
:cmock:
:mock_prefix: mock_
:when_no_prototypes: :warn
:enforce_strict_ordering: TRUE
:plugins:
- :ignore
- :callback
:treat_as:
uint8: HEX8
uint16: HEX16
uint32: UINT32
int8: INT8
bool: UINT8
:tools:
:test_compiler:
:executable: iccarm
:name: 'IAR test compiler'
:arguments:
- -D _DLIB_FILE_DESCRIPTOR=1
- --debug
- --endian=little
- --cpu=Cortex-M3
- -e
- --fpu=None
- -Ol
- --preprocess "build/test/list"
- --dlib_config "C:/Program Files (x86)/IAR Systems/Embedded Workbench 6.5/arm/INC/c/DLib_Config_Normal.h"
- -I"$": COLLECTION_PATHS_TEST_TOOLCHAIN_INCLUDE
- -I"$": COLLECTION_PATHS_TEST_SUPPORT_SOURCE_INCLUDE_VENDOR
- -o "${2}"
- --diag_suppress=Pa050
- '"${1}"'
:test_linker:
:executable: ilinkarm
:name: 'IAR test linker'
:arguments:
- --vfe
- --redirect _Printf=_PrintfFull
- --redirect _Scanf=_ScanfFull
- --semihosting
- --config "C:/Program Files (x86)/IAR Systems/Embedded Workbench 6.5/arm/config/generic_cortex.icf"
- --map "build/test/tests.map"
- -o "${2}"
- '"${1}"'
:test_fixture:
:executable: cspybat
:name: 'CSpyBat test runner'
:arguments:
- '"C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\bin\armproc.dll"'
- '"C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\bin\armsim2.dll"'
- '"${1}"'
- --plugin "C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\arm\bin\armbat.dll"
- --backend -B
- --endian=little
- --cpu=Cortex-M3
- --fpu=None
- --semihosting
:plugins:
:load_paths:
- vendor/ceedling/plugins
:enabled:
- stdout_pretty_tests_report
- module_generator
...
This seems to be a suitable configuration for testing code designed to work on a Cortex-M3 device.
I also edited rakefile.rb to ensure that the generated test files are cleaned before each test run, as this was necessary to have the test results get printed consistently.
PROJECT_CEEDLING_ROOT = "vendor/ceedling"
load "#{PROJECT_CEEDLING_ROOT}/lib/ceedling.rb"
Ceedling.load_project
task :default => %w[ clean test:all ]
I was then able to define and run unit tests. Below is an excerpt from test_canDatabase.c:
#include "unity.h"
#include "canDatabase.h"
uint32_t actualId;
uint8_t actualPayload[8];
uint8_t actualPayloadLen;
uint8_t actualCanPort;
void mockHandler(uint32_t id, uint8_t payload[8], uint8_t payloadLen, uint8_t canPort)
{
actualId = id;
actualPayloadLen = payloadLen;
actualCanPort = canPort;
for (int i=0; i < payloadLen; i++)
{
actualPayload[i] = payload[i];
}
}
void setUp(void)
{
actualId = 0;
actualPayloadLen = 0;
actualCanPort = 0;
for (int i=0; i < 8; i++)
{
actualPayload[i] = 0;
}
CANDB_Init(mockHandler);
}
void tearDown(void) {}
void test_Register_Tx_Definition()
{
// GIVEN a CAN Tx message definition.
CAN_TX_MESSAGE_DEFINITION_T definition;
definition.id = 0;
// WHEN we register the definition in the CAN database.
int err = CANDB_RegisterTxDefinition(definition);
// THEN the database should return SUCCESS (0x0).
TEST_ASSERT_EQUAL_MESSAGE(0x0, err, "Registration should succeed");
}
void test_Register_Tx_Definition_Twice()
{
// GIVEN a CAN Tx message definition.
CAN_TX_MESSAGE_DEFINITION_T definition;
definition.id = 0;
// WHEN we register the definition once.
CANDB_RegisterTxDefinition(definition);
// AND we register the definition again.
int err = CANDB_RegisterTxDefinition(definition);
// THEN the database should return SUCCESS (0x0).
TEST_ASSERT_EQUAL_MESSAGE(0x0, err, "Re-registration should succeed");
}
I'm now able to run automated tests by invoking "ceedling" from a terminal (project root is the current working directory):
$ ceedling
---------------------
BUILD FAILURE SUMMARY
---------------------
Unit test failures.
Cleaning build artifacts...
(For large projects, this task may take a long time to complete)
Test 'test_canDatabase.c'
-------------------------
Generating runner for test_canDatabase.c...
Compiling test_canDatabase_runner.c...
Compiling test_canDatabase.c...
Compiling unity.c...
Compiling canDatabase.c...
Compiling cmock.c...
Linking test_canDatabase.out...
Running test_canDatabase.out...
-----------
TEST OUTPUT
-----------
[test_canDatabase.c]
- ""
- " IAR C-SPY Command Line Utility V6.6.0.2752"
- " Copyright 2000-2013 IAR Systems AB."
- ""
- ""
-------------------
FAILED TEST SUMMARY
-------------------
[test_canDatabase.c]
Test: test_Register_More_Than_Max_Allowed_Definitions
At line (84): "Expected 1 Was 0. Registration > CANDB_MAX_TX_DEFINITIONS should fail"
Test: test_Activate_Tx_Definition_With_Hardcoded_Payload
At line (124): "Expected 0x00000001 Was 0x00000000. Incorrect ID"
--------------------
OVERALL TEST SUMMARY
--------------------
TESTED: 4
PASSED: 2
FAILED: 2
IGNORED: 0
Your answer was super helpful and I'm working on similar approach for Cortex-M4 with IAR 7.5 and thought of sharing my portions of project.yml additions.
:tools:
:test_compiler:
:executable: iccarm
:name: 'IAR test compiler'
:arguments:
- -D _DLIB_FILE_DESCRIPTOR=1
- --diag_suppress Pa050,Pa082,Pa039,Pe186
- --no_cse
- --no_unroll
- --no_inline
- --no_code_motion
- --no_tbaa
- --no_clustering
- --no_scheduling
- --debug
- --endian=little
- --cpu=Cortex-M4
- -e
- --fpu=VFPv4_sp
- --dlib_config "C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\INC\c\DLib_Config_Normal.h"
- --preprocess "build/test/list"
- -On
- --c++
- --no_exceptions
- --no_rtti
- -I"$": COLLECTION_PATHS_TEST_TOOLCHAIN_INCLUDE
- -I"$": COLLECTION_PATHS_TEST_SUPPORT_SOURCE_INCLUDE_VENDOR
- -o "${2}"
- '"${1}"'
:test_linker:
:executable: ilinkarm
:name: 'IAR test linker'
:arguments:
- --vfe
- --redirect _Printf=_PrintfFull
- --redirect _Scanf=_ScanfFull
- --semihosting
- --keep __checksum
- --entry __iar_program_start
- --place_holder __checksum,4,.checksum,4
- --define_symbol __checksum_begin=0x8020000
- --define_symbol __checksum_end=0x80dfffb
- --no_exceptions
- --config "C:\Users\jseinfeld\RubymineProjects\m4\common\cb\proj\flash.icf"
- --map "build/test/m4.map"
- -o "${2}"
- '"${1}"'
:test_fixture:
:executable: cspybat
:name: 'CSpyBat test runner'
:arguments:
- '"C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\bin\armproc.dll"'
- '"C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\bin\armsim2.dll"'
- '"${1}"'
- --plugin "C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\bin\armbat.dll"
- --backend -B
- --endian=little
- --cpu=Cortex-M4
- --fpu=VFPv4_sp
- --semihosting
i don't exactly understand the manual/help from libcURL. I'm trying to build a Cross-Compiler including the libcURL library. I installed a Cross-Compiler on my Server with the help of this video and can start it with arm-linux-gnueabihf-gcc hello_simple.c. I could compile simple c-code like printf ("Hello World"); After that i tried to install libcURL and read that I need to compile the lib and use the configure file to set the build and host. I used different configuration like: sudo ./configure --build=i586-pc-linux-gnu --host=arm-linux --target=arm-linux --prefix=/home/nevadmin/dev/gcc but neither did one worked. I think I'm making somewhere mistakes. This is the output after configuration is made:
curl version: 7.46.0
Host setup: arm-unknown-linux-gnu
Install prefix: /home/nevadmin/dev/gcc
Compiler: gcc
SSL support: no (--with-{ssl,gnutls,nss,polarssl,mbedtls,cyassl,axtls,winssl,darwinssl} )
SSH support: no (--with-libssh2)
zlib support: no (--with-zlib)
GSS-API support: no (--with-gssapi)
TLS-SRP support: no (--enable-tls-srp)
resolver: default (--enable-ares / --enable-threaded-resolver)
IPv6 support: no (--enable-ipv6)
Unix sockets support: enabled
IDN support: no (--with-{libidn,winidn})
Build libcurl: Shared=yes, Static=yes
Built-in manual: enabled
--libcurl option: enabled (--disable-libcurl-option)
Verbose errors: enabled (--disable-verbose)
SSPI support: no (--enable-sspi)
ca cert bundle: no
ca cert path: no
LDAP support: no (--enable-ldap / --with-ldap-lib / --with-lber-lib)
LDAPS support: no (--enable-ldaps)
RTSP support: enabled
RTMP support: no (--with-librtmp)
metalink support: no (--with-libmetalink)
PSL support: no (libpsl not found)
HTTP2 support: disabled (--with-nghttp2)
Protocols: DICT FILE FTP GOPHER HTTP IMAP POP3 RTSP SMTP TELNET TFTP
My Server cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU E5649 # 2.53GHz
stepping : 2
microcode : 0x15
cpu MHz : 2533.423
cache size : 12288 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat dtherm
bogomips : 5066.84
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
And my controller:
Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 298.80
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Using for example gcc hello_world.c -o hello_world it compile it for the amd processor architecture and not arm. It seems I'm missing the linking to the library for libcURL? I appreciate every help. And sorry my english, it's not my native language.
Linking with L/home/nevadmin/dev/gcc -lcurl is working an I can compile a c-code with libcURL but it still compiling it for amd64 and not arm. :/
You need to set the proper compiler to use when you configure curl. If you look at curl's configure output from
./configure --help
You'll see this at the end:
...
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
You can set these variables with a command line like:
CC=arm-linux-gnueabihf-gcc ./configure --build=i586-pc-linux-gnu --host=arm-linux --target=arm-linux --prefix=/home/nevadmin/dev/gcc
(You don't need the "sudo" to configure.)
gcc by itself will give you an AMD executable. You need to use arm-linux-gnueabihf-gcc to get an ARM executable.
Notice that in your curl configuration output it says
Compiler: gcc
That's why your getting a curl library built for your AMD. Bibliothek is called "library" in English. ;-)
If you continue to have problems cross compiling for ARM you could take a look at the binary releases of the cross compilation tool chain ELLCC. As of version 0.1.21 it comes with several pre-compiled libraries, including curl. Here's the ChangeLog.
hi there i have a problem to generate a debian package
i have 2 files to install 1 is a BASH SCRIPT
the other is .DESKTOP FILE
/kate-folder-service-menu-0.1.0$ tree
.
└── usr
├── bin
│ └── ktexeditor-open-folder
└── share
└── kde4
└── services
└── ServiceMenus
└── kate-folder.desktop
Now i have created all the stuff, with
dh_make -s -c gpl
i have edited:
-control file
-copyright file
-rules file
in the rules file i have made :
#!/usr/bin/make -f
# %:
# dh $# --with-lzma
# -*- makefile -*-
# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1
configure: configure-stamp
configure-stamp:
dh_testdir
touch configure-stamp
build: build-stamp
build-stamp: configure-stamp
dh_testdir
touch $#
clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
binary-indep: build install
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs
dh_installexamples
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
install --mode=777 -t debian/usr/bin usr/bin/ktexeditor-open-folder
install --mode=644 -t debian/usr/share/kde4/services/ServiceMenus usr/share/kde4/services/ServiceMenus/kate-folder.desktop
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
now i did
debuild -uc -us --source-option=--include-binaries --source-option=-isession
and finally this
sudo pbuilder build MYSTUFF.dsc
but this bastard generates the debian package without the script and the service menu :D
dpkg --contents kate-folder-service-menu_0.1.0-1_i386.deb
drwxr-xr-x root/root 0 2012-04-14 14:53 ./
drwxr-xr-x root/root 0 2012-04-14 14:53 ./usr/
drwxr-xr-x root/root 0 2012-04-14 14:53 ./usr/share/
drwxr-xr-x root/root 0 2012-04-14 14:53 ./usr/share/doc/
drwxr-xr-x root/root 0 2012-04-14 14:53 ./usr/share/doc/kate-folder-service-menu/
-rw-r--r-- root/root 201 2012-04-12 11:16 ./usr/share/doc/kate-folder-service-menu/README.Debian
-rw-r--r-- root/root 1239 2012-04-12 15:31 ./usr/share/doc/kate-folder-service-menu/copyright
-rw-r--r-- root/root 152 2012-04-12 15:55 ./usr/share/doc/kate-folder-service-menu/changelog.Debian.gz
That must be an ancient dh_make if it's giving you old-style debhelper rules.
I suggest a modern minimal debian/rules:
#!/usr/bin/make -f
%:
dh $#
Then put this in debian/install:
usr/bin/ktexeditor-open-folder
usr/share/kde4/services/ServiceMenus/kate-folder.desktop
That'll use dh_install to put them in the right place, and do all the other usual stuff to generate the package.