I compiled my codebase in a fc11 linux pc and getting following error.
Archive: [libexam.a]
Usage: mipsel-linux-ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV] [member-name][count] archive-file file...
mipsel-linux-ar -M [<mri-script]
commands:
d - delete file(s) from the archive
m[ab] - move file(s) in the archive
p - print file(s) found in the archive
q[f] - quick append file(s) to the archive
r[ab][f][u] - replace existing or insert new file(s) into the archive
t - display contents of archive
x[o] - extract file(s) from the archive
command specific modifiers:
[a] - put file(s) after [member-name]
[b] - put file(s) before [member-name] (same as [i])
[D] - use zero for timestamps and uids/gids
[N] - use instance [count] of name
[f] - truncate inserted file names
[P] - use full path names when matching
[o] - preserve original dates
[u] - only replace files that are newer than current archive contents
generic modifiers:
[c] - do not warn if the library had to be created
[s] - create an archive index (cf. ranlib)
[S] - do not build a symbol table
[T] - make a thin archive
[v] - be verbose
[V] - display the version number
#<file> - read options from <file>
emulation options:
No emulation specific options
mipsel-linux-ar: supported targets: elf32-tradlittlemips elf32-tradbigmips ecoff- littlemips ecoff-bigmips elf32-ntradlittlemips elf64-tradlittlemips elf32-ntradbigmips elf64-tradbigmips elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make[3]: *** [core/linuxuser.mipsel-uclibc/libexam.a] Error 1
make[2]: *** [default] Error 2
make[1]: *** [build-exam] Error 2
make: *** [app] Error 2
Could anyone help me in identifying what is this error meant for?
Note: I mentioned specific because i am getting this error in one specific fc11 pc only. I compared the uname -a between the working and not working pc, both are same. Did any one confirm does it requires for any specific package to be installed for this.
Related
I have a QEMU VM running an image of the Linux kernel 4.14.78.
On the host machine (a server with 96 cores), I am trying to compile a new update for the kernel with some changes I have made.
To make this process faster, I was using the host machine to compile for the target VM.
To do that I follow these steps:
copy the /boot/config-4.14.78 file from VM to host
put the copied file into the kernel source-code root directory, renaming it to .config in my
run make clean to clean it
run make menuconfig just to update the configs
run make -j$(nproc)
However, I am getting this error:
AS arch/x86/purgatory/setup-x86_64.o
CC arch/x86/purgatory/sha256.o
AS arch/x86/purgatory/entry64.o
CC arch/x86/purgatory/string.o
In file included from scripts/selinux/mdp/mdp.c:49:
./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map.
245 | #error New address family defined, please update secclass_map.
| ^~~~~
make[3]: *** [scripts/Makefile.host:102: scripts/selinux/mdp/mdp] Error 1
make[2]: *** [scripts/Makefile.build:587: scripts/selinux/mdp] Error 2
make[2]: *** Waiting for unfinished jobs....
In file included from scripts/selinux/genheaders/genheaders.c:19:
./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map.
245 | #error New address family defined, please update secclass_map.
| ^~~~~
CHK scripts/mod/devicetable-offsets.h
make[3]: *** [scripts/Makefile.host:102: scripts/selinux/genheaders/genheaders] Error 1
make[2]: *** [scripts/Makefile.build:587: scripts/selinux/genheaders] Error 2
make[1]: *** [scripts/Makefile.build:587: scripts/selinux] Error 2
make[1]: *** Waiting for unfinished jobs....
I have checked what causes this, and turns out that it is because of the:
include/linux/socket.h:211:#define AF_MAX 44 /* For now.. */
include/linux/socket.h:260:#define PF_MAX AF_MAX
Then, I followed this solution to print out the definition of PF_MAX at preprocessing time, and turns out that the PF_MAX is 45:
In file included from scripts/selinux/mdp/mdp.c:49:
./security/selinux/include/classmap.h:247:9: note: #pragma message: 45
247 | #pragma message(STRING(PF_MAX))
| ^~~~~~~
./security/selinux/include/classmap.h:250:2: error: #error New address family defined, please update secclass_map.
250 | #error New address family defined, please update secclass_map.
| ^~~~~
This 45 makes no sense for me, because I just checked that it is supposed to be 44.
I wonder if the build is considering the host machine instead of the target?
P.S.: These steps works fine on my local machine, which is a 8-cores machine, look the kernel version:
uname -a
Linux campes-note 5.4.86 #1 SMP Fri Jan 1 16:26:25 -03 2021 x86_64 x86_64 x86_64 GNU/Linux
UPDATE 1:
I tried to compile the kernel without any of my changes, following th above steps mentioned, and it did not compile as well, I get the same error.
UPDATE 2:
I found out that somehow, the compilation is looking at the host /usr/src/linux-headers-x.x.x files.
Instead, it should point to the same version as the target.
For that, I tried to follow this tutorial but I did not success. I am having a problem in one of the steps stated on this tutorial.
(Gathered from the now removed comments)
I have tried myself to build myself v4.14.78 followed by the latest available v4.14.214. I have found that former fails while the latter builds. So, I have bisected down to v4.14.116 that first builds correctly. Then I simple looked into the changes and found commit 760f8522ce08 ("selinux: use kernel linux/socket.h for genheaders and mdp") in the Linux stable tree which fixes the issue.
You may try to cherry-pick it to your branch and compile again.
I'm doing crash analysis on some software,and I'm sure there is no pdb file I can get for the sth.exe,but when sth.exe crashs,every time windbg will search a lot of paths and symbol servers.Even when I cut off the vm's network connection,it still pinned for a while to search the sth.exe's pdb.And this leads to a failure in my auto analysis.Is there a way to tell windbg sth.exe has no pdb,please don't waste time to search it?
create a file named symsrv.ini
in the folder where windbg is installed
the directory in this sample is e:\ewdk\program files\windows kits\10\Debuggers\x86
create an exclusion section in the file
and add all the unknown pdb's list into it
symsrv wont go searching for them
:\>ls -l symsrv.ini
-rw-rw-rw- 1 HP 0 259 2016-08-18 17:43 symsrv.ini
:\>file symsrv.ini
symsrv.ini; ASCII text, with CRLF line terminators
:\>cat symsrv.ini
[exclusions]
livekdD.sys
vmm.pdb
livekdD.pdb
vmci.pdb
vsock.pdb
clwvd.pdb
spldr.pdb
vmkbd.pdb
vmnetsrv.pdb
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
:\>livekd
LiveKd v5.40 - Execute kd/windbg on a live system
Sysinternals - www.sysinternals.com
!sym noisy
noisy mode - symbol prompts off
kd> .reload /f
SYMSRV: vmci.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1141980\bora-vmsoft\build\release\crosstalk\windows\wi
n2k\i386\vmci.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vmci.sys -
DBGHELP: vmci - export symbols
SYMSRV: vsock.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1253991\bora-vmsoft\build\release\vsock\windows\win2k\
i386\vsock.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vsock.sys -
DBGHELP: vsock - export symbols
SYMSRV: vmm.pdb is in the file exclusion list
DBGHELP: m:\src\built\vs2005.sp2\vssp2\usa\ent_volume\i386\sym\sys\vmm.pdb - fil
e not found
*** ERROR: Module load completed but symbols could not be loaded for vmm.sys
DBGHELP: vmm - no symbols loaded
************* Symbol Loading Error Summary **************
Module name Error
vmci The system cannot find the file specified : srv*e:\symbols*
http://msdl.microsoft.com/download/symbols The SYMSRV client
failed to find a file in the UNC store, or there is an invalid
UNC store (an invalid path or thepingme.txt file is not present
in the root directory), or the fileis present
in the symbol server exclusion list.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
answer to comment
well for a start there is a setting up exclusion list topic in windbg help
this topic alludes to this file (file is alluded in respect to using the symproxy and is supposed to be created at %windowsdir\system32\inetsrv\" and doesnt work for symsrv.dll (the registry key also doesnt seem to work )
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556870(v=vs.85).aspx
for me i saw in procmon a failure with NameNotFound error in fastio path in windbg installation directory
so on a hunch i moved the file from above mentioned path to windbg installation directory
and things seemed to work correctly that was very long back
but subsequently i've seen post from jason shay (MSFT) in osr windbg lists stating this feature was pushed in windbg 6.4.4 beta
http://www.osronline.com/showthread.cfm?link=68916
so there isn't any common sense missing just that the corner cases are always difficult to find
Has anyone encountered the error below when compiling omniORB_4.1.6 64-bit for windows?
'RegQueryValueEx failed - error 109'
I followed the procedure in the readme.win32 and I get linking errors in the omniDyamic, codesets etc.. So someone suggested to rebuild the omniorb_root/src/tools/win32 and copy it in bin/x86_win32/. That's what I did and when I recompile the whole omniORB, the error is as below:
../../../../bin/x86_win32/omkdepend -D__cplusplus -D_MSC_VER -DIDLMODULE_VERSION
="0x2630" -DMSDOS -DOMNIIDL_EXECUTABLE -Ic:/python27/include -Ic:/python27/PC -I
c:/python27/include/python2.7 -DPYTHON_INCLUDE=<Python.h> -I. -I. -I../../../../
include -D__WIN32__ -D_WIN32_WINNT=0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -
D_CRT_SECURE_NO_DEPRECATE=1 idlc.cc idlpython.cc idlfixed.cc idlconfig.cc idldum
p.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idl
util.cc idlerr.cc lex.yy.cc y.tab.cc
RegQueryValueEx failed - error 109
-----------------------------------------------------------------------------------------------
make[4]: Entering directory `/cygdrive/c/Software/COTS/omniORB/omniORB_4.1.6/src
/tool/omniidl/cxx/cccp'
../../../../../bin/x86_win32/clwrapper -gnuwin32 -c -O2 -MD -GS -GR -Zi -nologo
-DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D__WIN32__ -D_WIN32_WINNT=
0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -D_CRT_SECURE_NO_DEPRECATE=1 -Focexp
.o cexp.c
RegQueryValueEx failed - error 109
I'm going to answer my own question because it seems nobody has encountered this problem, and the mailing list is so quiet.
Someone suggested to me to recompile the src\tools\win32. So that's what I did and I copied the .exe files generated to bin\x86_win32.
I then compiled all the omniORB and get the RegQueryValueEx error.
The reason for this is when you check the src\tools\win32\bccwrapper.c in the void GetMounts(void) function,
it looks for this path in the registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
When I checked that using regedit, I noticed that in the mounts->00, 01, 02, 03 etc.. keys, there are no 'unix' and 'native' string values inside those keys.
So I decided to delete all the keys and retained just the 00 and added a 'unix' and 'native' string value.
After which, I recompiled the src\tools\win32 and copied over the created .exe files to bin\x86_win32 and finally when I recompiled all the omniOrb, it started compiling (need to copy the ssl libs too) and finished successfully.
I really don't even know how the following got into my registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
Best regards,
Mark
I spent quite some time trying to compile OmniORB on windows 10 with visual studio 2017.
Assuming Cygwin64 was installed in directory
c:\software\cygwin64
, the compilation of OmniORB is quite straightforward:
open a command terminal (cmd)
in that terminal, setup the Visual environment:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
then, append the PATH (yes append and not prepend):
set PATH=%PATH%;c:\software\cygwin64\bin
then, in file config\config.mk, uncomment this line
platform = x86_win32_vs_15
in file platforms\x86_win32_vs_15, set PYTHON to target the python executable, in my case Python 3.6.5
PYTHON = /cygdrive/c/software/Python/python
finally start the compilation with make:
make export
Hope this helps.
I am trying to compile PJSIP on Ubuntu according to this document:
http://supportforums.blackberry.com/t5/Native-Development/Porting-PJSIP-PJMEDIA-and-PJLIB-to-BlackBerry-10/ta-p/2085751
When I am executing this command: ./buildpjsip (it's on number 8 in document), it is showing these errors:
cp: cannot create regular file /x86/lib': No such file or directory
/home/ahsish/bb10-pjsipdemo-master/pjbuildscripts/pjsip-build /home/ahsish/bb10-pjsipdemo-master/pjbuildscripts
/home/ahsish/bb10-pjsipdemo-master/pjbuildscripts/pjsip-build/trunk /home/ahsish/bb10-pjsipdemo-master/pjbuildscripts/pjsip-build /home/ahsish/bb10-pjsipdemo-master/pjbuildscripts
Makefile:1: build.mak: No such file or directory
Makefile:2: build/host-.mak: No such file or directory
make: *** No rule to make target `build/host-.mak'. Stop.
checking build system type... i686-pc-linux-gnu
checking host system type... i486-pc-nto-qnx8.0.0
checking target system type... i486-pc-nto-qnx8.0.0
checking for i486-pc-nto-qnx8.0.0-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
aconfigure: error: in `/home/ahsish/bb10-pjsipdemo-master/pjbuildscripts/pjsip-build/trunk':
aconfigure: error: C compiler cannot create executables
See `config.log' for more details
Makefile:1: build.mak: No such file or directory
Makefile:2: build/host-.mak: No such file or directory
make: *** No rule to make target `build/host-.mak'. Stop.
Makefile:1: build.mak: No such file or directory
Makefile:2: build/host-.mak: No such file or directory
make: *** No rule to make target `build/host-.mak'. Stop.
/home/ahsish/bb10-pjsipdemo-master/pjbuildscripts/pjsip-build /home/ahsish/bb10-pjsipdemo-master/pjbuildscripts
adding: libopencore-amrwb.a (deflated 67%) adding: libopencore-amrnb.a (deflated 70%)
/home/ahsish/bb10-pjsipdemo-master/pjbuildscripts*
I also encountered the issue before and solved it successfully. I think what results in the issue is that, after you executed the step 4 in the document: Execute bbndk-env.bat or bbndk-env.sh from the root of your installation of the Native SDK. You shouldn't close the command prompt or open a new terminal. I mean you should execute the rest steps in the same terminal, then you will build the library successfully. Also, you had better ensure your gcc is the newest version. Good luck for you.
You could try first:
$ cd bb10-pjsipdemo/pjbuildscripts/pjsip-checkout/trunk
$ ./configure
$ touch pjlib/include/pj/config_site.h
$ make dep
$ make
Reference: http://www.pjsip.org/pjlib/docs/html/pjlib_build_sys_pg.htm
And then run bb10-pjsipdemo/pjbuildscripts/buildpjsip
Every build has failed as of Tuesday. I'm not exactly sure what happened. The Phing targets (clean/prepare) are being executed properly. Additionally, the unit tests are passing with flying colors, with only a warning for duplicate code (not a reason for a fail). I tried removing the phpDoc target to see if that was causing the error, but the build still failed.
Started by user chris Updating
file://localhost/projects/svn/ips-com/trunk
At revision 234 no change for
file://localhost/projects/svn/ips-com/trunk
since the previous build [trunk] $
/opt/phing/bin/phing clean prepare
-logger phing.listener.NoBannerLogger Buildfile:
/var/lib/hudson/.hudson/jobs/IPS/workspace/trunk/build.xml
IPS > clean:
[echo] Clean... [delete] Deleting directory
/var/lib/hudson/.hudson/jobs/IPS/workspace/build
IPS > prepare:
[echo] Prepare...
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/coverage
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/coverage-html
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/docs
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/app
BUILD FINISHED
Total time: 1.0244 second
[workspace] $ /bin/bash -xe
/tmp/hudson3259012225710915845.sh
+ cd trunk/tests
+ /usr/local/bin/phpunit --verbose -d memory_limit=512M --log-junit
../../build/logs/phpunit.xml
--coverage-clover ../../build/logs/coverage/clover.xml
--coverage-html ../../build/logs/coverage-html/
PHPUnit 3.5.0 by Sebastian Bergmann.
IPS Default_IndexControllerTest .
Default_AuthControllerTest ......
Manage_UsersControllerTest .....
testDeleteInvalidUserId ..
testGetPermissionsForInvalidUserId .. Audit_OverviewControllerTest
............
Time: 14 seconds, Memory: 61.00Mb
[30;42m[2KOK (28 tests, 198
assertions) [0m[2K Writing code
coverage data to XML file, this may
take a moment.
Generating code coverage report, this
may take a moment.
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
[workspace] $ /bin/bash -xe
/tmp/hudson1439023061736436000.sh
+ /usr/local/bin/phpcpd --log-pmd ./build/logs/cpd.xml ./trunk phpcpd
1.3.2 by Sebastian Bergmann.
Found 1 exact clones with 6 duplicated
lines in 2 files:
library/Ips/Form/Decorator/SplitInput.php:8-14
library/Ips/Form/Decorator/FeetInches.php:10-16
0.04% duplicated lines out of 16585 total lines of code.
Time: 4 seconds, Memory: 19.50Mb [DRY]
Skipping publisher since build result
is FAILURE Publishing Javadoc [xUnit]
[INFO] - Starting to record. [xUnit]
[WARNING] - Can't create the path
/var/lib/hudson/.hudson/jobs/IPS/workspace/generatedJUnitFiles.
Maybe the directory already exists.
[xUnit] [INFO] - Processing
PHPUnit-3.4 (default) [xUnit] [INFO] -
[PHPUnit-3.4 (default)] - 1 test
report file(s) were found with the
pattern 'build/logs/phpunit.xml'
relative to
'/var/lib/hudson/.hudson/jobs/IPS/workspace'
for the testing framework 'PHPUnit-3.4
(default)'. [xUnit] [INFO] -
Converting
'/var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/phpunit.xml'
. [xUnit] [INFO] - Stopping recording.
Publishing Clover coverage report...
Publishing Clover XML report...
Publishing Clover coverage results...
Finished: FAILURE
What changed since Tuesday? Try to manually run exactly the same commands that Hudson tries to run from the same directory that Hudson starts it from (usually the jobs workspace directory). Of course with the user account that Hudson is started under.
There are several possibilities. ranging from standard groups for a directory, to permission, or other things outside of Hudson. Was Hudson upgraded? Was a plugin upgraded? Was the OS or php upgraded? Was there a change in the default or user .profile or .env (or the equivalent files)? Does another process accesses the workspace? ......
Once I had the problem that all of the sudden my deployment scripts did not run anymore. The mystery was, that I could still run the script from command line with the Hudson user account. The reason was simple but took a while to uncover. There was a java upgrade from 5 to 6. Both versions were available. After comparing the environment variables, there was a difference in the path. The problem was that the new path was set in the global .profile. But Hudson does not open an interactive shell, therefore the .profile will not be executed. If you have a problem like this, you can put the initialization in the .env file (or whatever the filename is for your system), because this will be run regardless if it is a interactive shell or not. Alternatively you can configure Hudson to set it on master or node/slave level.
if you want a command to not break the 'build' as a failure you have to add #! in front of the command to prevent the flags -xe which produce this behaviour.