I am working on a Linux From Scratch project and I've run into some (potential) issues. In chapter 6.49: Libffi-3.2.1, I executed the "sed", "configure" and "make" commands successfully but when I executed "make check", it appears that every test fails:
MAKE x86_64-unknown-linux-gnu : 0 * check
...stuff...
Test run by root on Fri Jul 13 23:51:21 2018
Native configuration is x86_64-unknown-linux-gnu
=== libffi tests ===
Schedule of variations:
unix
Running target unix
...a lot of failures...
FAIL: libffi.call/va_struct3.c -W -Wall -Wno-psabi -Os (test for excess errors)
FAIL: libffi.call/va_struct3.c -W -Wall -Wno-psabi -O2 -fomit-frame-pointer (test for excess errors)
=== libffi Summary ===
# of unexpected failures 685
# of unresolved testcases 685
I've been following the book pretty closely, but maybe I missed something along the way. Should I even worry about this or should I just install it anyway and move on?
Let me know if more information is needed.
Nevermind, I solved it. I basically went back and redid everything.
I usually I copy and paste the commands from the LFS book into a bash script and run it that way (if I can get a away with it). Well, apparently I forgot to write one for the diffutils package. But this seems strange to me because I wouldn't think that missing that script would cause issues with a test that seems to use DejaGNU let alone get me that far without any troubles.
Anyway, my LFS is up and running now! š
Related
Hi I use fedora23 to calculate matrix.
So I am trying to install CLAPACK-3.2.1 to my computer.
In the procedure,
1. download clapack.tgz (version 3.2.1) from www.netlib.org/clapack -> done
2. cd CLAPACK-3.2.1 and cp make.inc.example make.inc -> done
3. make f2clib -> done properly
4. make blaslib -> done properly
5. make (this takes a while) -> problem starts here.
in a procedure of make, there are two errors. The error message is this.
make[2]: Leaving directory '/home/optics/CLAPACK/TESTING/EIG'
NEP: Testing Nonsymmetric Eigenvalue Problem routines
./xeigtstz < nep.in > znep.out 2>&1
/bin/sh: line 1: 9412 Segmentation fault (core dumped) ./xeigtstz < nep.in > znep.out 2>&1
Makefile:438: recipe for target 'znep.out' failed
make[1]: *** [znep.out] Error 139
make[1]: Leaving directory '/home/optics/CLAPACK/TESTING'
Makefile:44: recipe for target 'lapack_testing' failed
make: *** [lapack_testing] Error 2
==============================================================================
I cannot understand this. Please help me dealing with these errors.
I have also encountered this problem and was able to resolve it by increasing the stack size using ulimit as suggested here. The following worked for me:
$ sudo ulimit -s 100000
Followed by running make as usual. If you would like a primer on what this command does, check out this question: What does āulimit -s unlimitedā do?. Basically, it increases the limits on the scratch space in memory allocated to a thread.
In Kubuntu 17.10 it worked in this way:
ulimit -s unlimited
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.
This call fails on Solaris with EACCES when ran as ordinary user:
sem_open(fileName.c_str(), O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO, 1);
When process is started as root, it runs fine. Is this expected behavior?
Environment:
$ uname -a
SunOS solaris 5.11 11.0 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 4.5.2
At the command line try:
prctl $$
These are the system enforced resource limits your process has. Note there are
process.max-sem-ops
process.max-sem-nsems
project.max-sem-ids
These are limits that have a number, if you do not see them (or the limits are already reached) then you have to add them to your account's profile with projadd or projmod to increase them if your project already exists.
If you cannot do this (no root access) consult with your sysadmin, s/he probably has some reason for not allowing semapahore access.
Note carefully:
sempahores are kernel persistent. If you ran your code a bunch of times the sempahores you created are likely still out there.
To see existing semaphores try ipcs -as
To remove lingering sempahores that your code should have removed use ipcrm
I have been trying to link Arduino and Eclipse, and I feel like I'm close.
Where should I start looking for this?
Similar errors have been caused by extra/incomplete quote blocks (according to google searches). I have already dug through my AVR linker settings looking for quotes, but haven't had much luck.
Am I looking in the right place?
Which files should I check?
I have already looked in the file I have written myself (in this case, the basic Arduino blink program).
**** Build of configuration Release for project C64_Arduino1 ****
make all
Building target: C64_Arduino1.elf
Invoking: AVR C++ Linker
avr-gcc --cref -s -Os -o"C64_Arduino1.elf" ./C64_Arduino1.o ./CDC.o ./HID.o
./HardwareSerial.o ./Print.o ./Stream.o ./Tone.o ./USBCore.o ./WInterrupts.o ./WMath.o ./WString.o ./malloc.o ./wiring.o ./wiring_analog.o ./wiring_digital.o ./wiring_pulse.o
./wiring_shift.o -l"Arduino_Mega_2560_or_Mega_ADK" -lm -L/Users/Chet/Desktop/Chet's Shit/Side Projects/Programming/C64_Arduino1/Release -L"/Users/Chet/Desktop/Chet's Shit/Side
Projects/Programming/C64_Arduino1" -mmcu=atmega2560
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [C64_Arduino1.elf] Error 2
**** Build Finished ****
EDIT:
I have commented out all of my code (including #include's) except the main (which is empty) and I still get the error. I have set up my IDE as specified Here and also Here. Still nothing.
Looking at the actual error message:
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
I can see that the problem is most likely due to some kind of Makefile syntax error.
When you write a make rule such like:
foo:
touch foo
What make does, it first checkes whether file called foo exists already, if not, then it runs command /bin/sh -c 'touch foo'. So the line where we said touch foo should have valid shell script syntax.
Looking at the command that you ended up running:
avr-gcc --cref -s -Os -o"C64_Arduino1.elf" ./C64_Arduino1.o ./CDC.o ./HID.o
./HardwareSerial.o ./Print.o ./Stream.o ./Tone.o ./USBCore.o ./WInterrupts.o ./WMath.o ./WString.o ./malloc.o ./wiring.o ./wiring_analog.o ./wiring_digital.o ./wiring_pulse.o
./wiring_shift.o -l"Arduino_Mega_2560_or_Mega_ADK" -lm -L/Users/Chet/Desktop/Chet's Shit/Side Projects/Programming/C64_Arduino1/Release -L"/Users/Chet/Desktop/Chet's Shit/Side
Projects/Programming/C64_Arduino1" -mmcu=atmega2560
I can see that the issue is with the ' character in some of the directory paths. You should either escape it (as in "/Users/Chet/Desktop/Chet\'s Shit") or, as a quick work-around symlink or move the directory.
As a general methodology tip, you should first check whether everything works in CLI, and then move on to teaching Eclipse what commands it should run.
Also, I would consider using the tool called ino instead of make, it might just work with minimum configuration. I have had some experience replacing Arduino IDE with just a Makefile, but it gets hairy when you need to use different boards and perhaps several connected at the same time. Give ino a try, it looks quite promising.
I have a Netgear ReadyNAS NV+ on which I'm trying to do some things using perl.
Since the perl installation from the vendor is compiled without the uselargefiles-flag I've tried to compile/install my own version to run in parallell with the system one.
When I first tried to compile perl on the machine itself I ran into trouble as the system is lacking alot of regular system tools which prevents the Configure-script from running properly.
# ./Configure -des -Dprefix=$HOME/perl-5.16.2
First let's make sure your kit is complete. Checking...
./Configure: line 1986: split: command not found
cat: /root/dload/perl-5.16.2/UU/x??: No such file or directory
Locating common programs...
I don't know where 'comm' is, and my life depends on it.
Go find a public domain implementation or fix your PATH setting!
To get around that I installed and used this cross-compiler to build perl on another machine.
I could not figure out how to cross-compile using the standard configure-script from perl, so I used this.
After that I could just copy my new perl-folder onto the NAS and have thing like the following work:
# ~/sparc-perl-5.16.2/bin/perl -version
This is perl 5, version 16, subversion 2 (v5.16.2) built for sparc-linux
Copyright 1987-2012, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
# ~/sparc-perl-5.16.2/bin/perl -e 'print "A string!\n";'
A string!
So in some sense I feel I've been successful in my quest to get "my" perl working on the machine.
I get in trouble when I try to install extra modules though.
I've tried installing Image::ExifTool using cpanp (among others), but the installation never finishes.
Today I resorted to trying the installation manually.
wget http://search.cpan.org/CPAN/authors/id/E/EX/EXIFTOOL/Image-ExifTool-9.12.tar.gz
tar xzf Image-ExifTool-9.12.tar.gz
cd Image-ExifTool-9.12
~/sparc-perl-5.16.2/bin/perl Makefile.pl
make
All work as they're supposed to.
when I get to make test however it hangs indefinitely like so:
# make test
PERL_DL_NONLAZY=1 /root/sparc-perl-5.16.2/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/AFCP.t ...........
Looking at the running processes I think these are the ones representing the command:
# ps aux | grep per[l]
root 26187 0.5 0.7 12000 7808 pts/0 S+ 10:31 0:07 /root/sparc-perl-5.16.2/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/AFCP.t t/AIFF.t t/APE.t t/ASF.t t/BigTIFF.t t/BMP.t t/CanonRaw.t t/Canon.t t/CanonVRD.t t/Casio.t t/DICOM.t t/DjVu.t t/DNG.t t/DV.t t/EXE.t t/ExifTool.t t/FLAC.t t/FlashPix.t t/Flash.t t/Font.t t/FotoStation.t t/FujiFilm.t t/Geotag.t t/GeoTiff.t t/GE.t t/GIF.t t/GIMP.t t/GPS.t t/HTML.t t/InDesign.t t/IPTC.t t/ITC.t t/Jpeg2000.t t/JVC.t t/Kodak.t t/KyoceraRaw.t t/Lang.t t/LNK.t t/M2TS.t t/Matroska.t t/MIE.t t/MIFF.t t/Minolta.t t/MP3.t t/MWG.t t/MXF.t t/Nikon.t t/Olympus.t t/OpenEXR.t t/Panasonic.t t/PDF.t t/Pentax.t t/PGF.t t/PhotoCD.t t/PhotoMechanic.t t/Photoshop.t t/PICT.t t/PNG.t t/PostScript.t t/PPM.t t/PSP.t t/QuickTime.t t/Radiance.t t/Real.t t/Ricoh.t t/RIFF.t t/RTF.t t/Sanyo.t t/Sigma.t t/Sony.t t/Unknown.t t/Vorbis.t t/Writer.t t/XMP.t t/ZIP.t
root 26189 1.7 0.0 0 0 pts/0 Z+ 10:31 0:24 [perl] <defunct>
This is completely consistent with what happens when I try the same installation using cpanp.
I guess I could just run make install and hope that it won't be to much of a problem that the test is unable to run/complete, but that makes me feel a bit uneasy. I'd much rather figure out what is wrong.
I also find it odd that the test hangs the way it does, I could accept that it fails, but that it just keeps running in a non-productive manner feels weird.
Since it is the first time I've built perl from source and the first time I've used a cross-compiler I would not be surprised to learn I've done something very wrong, any help identifying what is very welcome.
What am I doing wrong?
EDIT - compiling on the mahcine:
Figured out how to get the Configure script working natively on the machine.
Will try to build there to see if that will work better. It'll take some time though, the machine is slow.
To be able to run the configure script I needed:
GCC
apt-get install libc6-dev gcc gdb libtag1-dev uuid-dev
coreutils
apt-get install coreutils
-Dcc=gcc
./Configure -des -Dprefix=$HOME/perl-5.16.2 -Dcc=gcc
EDIT2 - compile failed:
Most shortlived success ever:
# make
`sh cflags "optimize='-O2'" perlmini.o` -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB perlmini.c
CCCMD = gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall
In file included from perl.c:33:
perl.h:699: error: conflicting types for `syscall'
/usr/include/unistd.h:939: error: previous declaration of `syscall'
ake: *** [perlmini.o] Error 1
EDIT3 - testdriving fork:
Tried the following to verify that fork works as it should. I believe that the test is successful, but I've never tried fork before, so please let me know if I read the output wrong.
# cat test_forkwait.px
#!/root/sparc-perl-5.16.2/bin/perl
$pid = fork();
die if $pid < 0;
$SIG{CHLD} = sub { warn "SIGCHLD\n"; };
if($pid) {
$status = waitpid($pid, 0);
warn "wait status: $status\n";
} else {
warn "Child starting\n";
sleep 1;
warn "Child terminating\n";
}
# ./test_forkwait.px
Child starting
Child terminating
SIGCHLD
wait status: 29913
I'm a bit late with this comment, and don't have any ideas about your "make test" hang, but I wanted to point out the Image::ExifTool is pure Perl, so it does not require compilation. The install step is as simple as copying the distribution files to the proper directories.
Phil
Gave up on figuring out why the test fails. Ended up using the module anyways. Seems to work OK with my files.