When I input gcc -v, it just shows the same...
I have try it in Debian and it behaves normally..
uname -i is non-portable according to man uname and it can be compiled out. My new Debian 8 also prints it as
$ uname -i
unknown
uname is part of the GNU coreutils and it is a very simple program. you can see the code on savannah. If you look through the command line option there --hardware-platform is -i:
88 static struct option const uname_long_options[] =
89 {
90 {"all", no_argument, NULL, 'a'},
...
97 {"machine", no_argument, NULL, 'm'},
98 {"processor", no_argument, NULL, 'p'},
99 {"hardware-platform", no_argument, NULL, 'i'},
100 {"operating-system", no_argument, NULL, 'o'},
101 {GETOPT_HELP_OPTION_DECL},
102 {GETOPT_VERSION_OPTION_DECL},
103 {NULL, 0, NULL, 0}
104 };
Which forces the printing of the define PRINT_HARDWARE_PLATFORM
198 while ((c = getopt_long (argc, argv, "asnrvmpio",
199 uname_long_options, NULL)) != -1)
200 {
201 switch (c)
202 {
...
227 case 'p':
228 toprint |= PRINT_PROCESSOR;
229 break;
230
231 case 'i':
232 toprint |= PRINT_HARDWARE_PLATFORM;
233 break;
Which, in turn does the printing of "unknown" by default.
344 if (toprint & PRINT_HARDWARE_PLATFORM)
345 {
346 char const *element = unknown;
347 #if HAVE_SYSINFO && defined SI_PLATFORM
348 {
349 static char hardware_platform[257];
350 if (0 <= sysinfo (SI_PLATFORM,
351 hardware_platform, sizeof hardware_platform))
352 element = hardware_platform;
353 }
354 #endif
If i am not mistaken (i might be) HAVE_SYSINFO should be in sys/systeminfo.h, and that file is not present by default in arch. That does not necessarily mean that it was not there when the package was compiled. Yet, it shows that, most likely, the packager did not bother compiling the package with HAVE_SYSINFO properly setup. Which is acceptable since it is a non-portable option.
See my comment about gcc -v, my arch evaluates it correctly to Target: x86_64-pc-linux-gnu. But that has nothing to do with uname, uname sends system calls to print information about the system, gcc has the target compiled into it.
Note: saying that uname is part of coreutils is not 100% correct. uname is part of the POSIX standard, yet the -i (--hardware-platform) option to uname is not part of that specification. -i is only implemented by the coreutils package (hell, *BSD systems have -i but it has a completely different meaning there).
Related
I am new to Arduino and working on a project to pass cryptographic keys between Arduino (ESP8266) and a React Native app. On the ESP8266 side I am using arduino crypto library and for React Native I am using react-native-crypto-js. The encryption doesn't seem to do the right thing and returns garbage. So, as a first step I was trying to pass the key from Arduino into the mobile app (using the bluetooth HC-05). The following code was used in the arduino side:
void getConnected() {
// wait till someone try to connect to the user
if (btSerial.available() > 0) {
String message = btSerial.readString();
if(message == "Hello") {
Serial.println("user trying to connect");
byte key[32];
device.getKey(key);
Serial.println((char*)key);
btSerial.write((char*)key);
}
}
}
The key is generated using RNG.rand(key, sizeof(key)) and I also printed the generated bytes separately and it is something like:
137 224 186 115 0 0 0 0 172 228 254 63 131 53 32 64 208 218 255 63 13 0 0 0 172 228 254 63 48 70 32 64
As you see above, since there are 0s in the bytes, the code in the React Native app is only getting the first 4 bytes, and the remaining is ignored as it is thinking the 5th byte to be the end of string.
The code used in the App is as below:
async setup(deviceId) {
console.log('connecting');
await BluetoothSerial.connect(deviceId);
console.log('connected');
await BluetoothSerial.write('Hello');
setTimeout(async () => {
let key = await BluetoothSerial.readFromDevice();
console.log(key);
}, 3000);
// const input = await BluetoothSerial.readFromDevice();
return true;
}
I would really appreciate some pointers. Please help.
Thanks
I built a simple program that executes a test in CUnit.
The main function is:
int main()
50 {
51 CU_pSuite pSuite = NULL;
52
53 /* initialize the CUnit test registry */
54 if (CUE_SUCCESS != CU_initialize_registry())
55 return CU_get_error();
56
57 /* add a suite to the registry */
58 pSuite = CU_add_suite("Suite_1", init_suite1, clean_suite1);
59 if (NULL == pSuite) {
60 CU_cleanup_registry();
61 return CU_get_error();
62 }
63
64 if ((NULL == CU_add_test(pSuite, "test of fprintf()", test_parse))) {
65 CU_cleanup_registry();
66 return CU_get_error();
67 }
68
69 /* Run all tests using the CUnit Basic interface */
70 CU_basic_set_mode(CU_BRM_VERBOSE);
71 CU_basic_run_tests();
72 CU_cleanup_registry();
73 printf("ERROR CODE: %d", CU_get_error());
74 return CU_get_error();
75 }
The test_parse function uses CU_ASSERT_FATAL. The test fails, but the output of main is the following:
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
Suite: Suite_1
Test: test of fprintf() ...FAILED
1. /home/fedetask/Desktop/curl/tests/main.c:42 - parsed == 3
Run Summary: Type Total Ran Passed Failed Inactive
suites 1 1 n/a 0 0
tests 1 1 0 1 0
asserts 5 5 4 1 n/a
Elapsed time = 0.000 seconds
ERROR CODE: 0
The main() returns 0. It returns 0 also if the test passes. What am I doing wrong?
My error: CU_get_error() returns an error code only if a framework function had an error, not the tests. To get test results, follow http://cunit.sourceforge.net/doc/running_tests.html
Ran into the same issue with this. Indeed, CU_get_error() will be 0 even if a testcase if failing. The following variables store the results as shown in the doc
unsigned int CU_get_number_of_suites_run(void)
unsigned int CU_get_number_of_suites_failed(void)
unsigned int CU_get_number_of_tests_run(void)
unsigned int CU_get_number_of_tests_failed(void)
unsigned int CU_get_number_of_asserts(void)
unsigned int CU_get_number_of_successes(void)
unsigned int CU_get_number_of_failures(void)
So a simple approach for checking if there has been any error, would be something like:
if (CU_get_number_of_tests_failed() != 0){
// Do Something
}
The xfce4 desktop environment goes black on random occasions during use.
Install xf86-video-ffbdev.
Will post updates here, and the solution as soon as I've found it.
$ uname -v
DragonFly v4.2.4-RELEASE #6: Sun Aug 9 13:25:14 EDT 2015 root#www.shiningsilence.com:/usr/obj/home/justin/release/4_2/sys/X86_64_GENERIC
n00b207: you shouldn't need xf86-video-fbdev (that warning is because how Xorg probes available devices)
$ pciconf -lv
hostb0#pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x0c008086 rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = '4th Gen Core Processor DRAM Controller'
class = bridge
subclass = HOST-PCI
vgapci0#pci0:0:2:0: class=0x030000 card=0xd0001458 chip=0x041e8086 rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = '4th Generation Core Processor Family Integrated Graphics Controller'
class = display
subclass = VGA
$ xset q
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
XKB indicators:
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
03: Shift Lock: off 04: Group 2: off 05: Mouse Keys: off
auto repeat delay: 500 repeat rate: 20
auto repeating keys: 00feffffdffffbbf
fedfffffffdfe5ef
ffffffffffffffff
ffffffffffffffff
bell percent: 0 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 2/1 threshold: 4
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 600 cycle: 600
Colors:
default colormap: 0x22 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/local/share/fonts/misc/,/usr/local/share/fonts/TTF/,/usr/local/share/fonts/OTF/,/usr/local/share/fonts/Type1/,/usr/local/share/fonts/100dpi/,/usr/local/share/fonts/75dpi/,built-ins
DPMS (Energy Star):
Standby: 600 Suspend: 600 Off: 600
DPMS is Enabled
Monitor is On
Font cache:
Server does not have the FontCache Extension
n00b207: could you try "xset dpms force off" to check if it freezes (might need to repeat few times to fully go into turn off screen mode)
dmesg output: http://pastebin.com/9tk5JCBf
n00b207: looks like you hit xfce+Xorg combo, try "xset -dpms && xset s noblank && xset s off" to see if it repeats again
I have an ARM-based device running Embedded Linux and I have observed that when I use the C library's system() call, the return code is incorrect. Here is a test program that demonstrates the behavior:
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
int ret = system("exit 42");
printf("Should return 42 for system() call: %d\n", ret);
printf("Returning 43 to shell..\n");
exit(43);
};
And here is the program output on the device:
# returnCodeTest
Should return 42 for system() call: 10752
Returning 43 to shell..
The value "10752" is returned by system() instead of "42". 10752 is 42 when left-shifted by 8:
Python 2.7.3 (default, Feb 27 2014, 20:00:17)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 42<<8
10752
So is suspect one of the following is going on somewhere:
The byte order is getting swapped
The value is getting shifted by 8 bits
Incompatible struct definitions are being used
When I run strace I see the following:
# strace /usr/bin/returnCodeTest
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x4001e308) = 977
wait4(977, [{WIFEXITED(s) && WEXITSTATUS(s) == 42}], 0, NULL) = 977
rt_sigaction(SIGINT, {SIG_DFL, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=977, si_status=42, si_utime=0, si_stime=0} ---
fstat64(1, {st_mode=S_IFCHR|0622, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001f000
write(1, "Should return 42 for system() ca"..., 42Should return 42 for system() call: 10752
) = 42
write(1, "Returning 43 to shell..\n", 24Returning 43 to shell..
) = 24
exit_group(43) = ?
+++ exited with 43 +++
wait4() returns with the correct status (si_status=42), but when it gets printed to standard output the value is shifted by 8 bits, and it looks like it is happening in a library. Interestingly the write returns a value of 42. I wonder if this is a hint as to what is going on...
Unfortunately I cannot get ltrace to compile and run on the device. Has anyone seen this type of behavior before or have any ideas (possibly architecture-specific) on where to look?
$man 3 system
Return Value
The value returned is -1 on error (e.g., fork(2) failed), and the
return status of the command otherwise. This latter return status is
in the format specified in wait(2). Thus, the exit code of the command
will be WEXITSTATUS(status).
$man 2 wait
WEXITSTATUS(status) returns the exit status of the child. This
consists of the least significant 8 bits of the status argument that
the child specified in a call to exit(3) or _exit(2) or as the
argument for a return statement in main(). This macro should only be
employed if WIFEXITED returned true.
I think exit codes are different from return values and is specific to OS.
Linux does the following when you call "exit" with a code.
(error_code&0xff)<<8
SYSCALL_DEFINE1(exit, int, error_code)
{
do_exit((error_code&0xff)<<8);
}
Take look at the below link (exit status codes in Linux).
Are there any standard exit status codes in Linux?
I've got the exception "unsupported version" when I try to deserialize through a text archive some data previously serialized with a upper version of Boost (1.46 to serialize and 1.38 to deserialize)...is there a way to downgrade (in the code) the serialization?
Something like "set_library_version"?
See the Error read binary archive, created by old Boost version mail archive post about the serialization error.
It says that the code below does the job:
void load_override(version_type & t, int version){
library_version_type lvt = this->get_library_version();
if (boost::archive::library_version_type(7) < lvt){
this->detail_common_iarchive::load_override(t, version);
}
else
if (boost::archive::library_version_type(6) < lvt){
uint_least16_t x = 0;
* this->This() >> x;
t = boost::archive::version_type(x);
}
else
if (boost::archive::library_version_type(3) == lvt ||
boost::archive::library_version_type(5) == lvt){
#pragma message("CTMS fix for serialization bug (lack of backwards compatibility) introduced by Boost 1.45.")
// Up to 255 versions
unsigned char x = 0;
* this->This() >> x;
t = version_type(x);
}
else{
unsigned int x = 0;
* this->This() >> x;
t = boost::archive::version_type(x);
}
}
Using text_archive ... I had a recent issue with this also.
I recently upgraded boost from 1.67 to 1.72 on Windows, generated some data on Windows. When I ran the data on my Linux environment which is still on Boost 1.67, it throws not supported.
The header for 1.67 looked like this
22 serialization::archive 16
and 1.72 looked like
22 serialization::archive 17
I changed 17 to 16 and it was happy for my use case.