I downloaded the WinFF source code in the hopes the new version would solve a segfault.
It's sitting, extracted, in its folder. But I see no ./configure, nothing make would know what to do with, no binaries, and no compilation instructions:
$ ls
AUTHORS COPYING README-Presets.txt unit2.lfm unit4.pas winff.1 winff.rc
changelog.txt docs README.txt unit2.pas unit5.lfm winff.ico
clean.bat languages RESOURCES.RC unit3.lfm unit5.pas winff-icons
clean.sh potranslator.pas unit1.lfm unit3.pas unit6.lfm winff.lpi
COMPILE.TXT presets.xml unit1.pas unit4.lfm unit6.pas winff.lpr
Does anyone know how I can try to actually compile the code?
All we get is a README.txt:
Winff - graphical video and audio batch converter using ffmpeg or
avconv Copyright © 2006-2012 Matthew Weatherford
http://www.winff.org
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
WinFF is a GUI for the command line video converter FFmpeg or avconv.
Get the latest ffmpeg builds and source from http://ffmpeg.org/
The answer is in COMPILE.TXT:
winff is compiled with lazbuild -B winff.lpr or manually in the
Lazarus IDE.
Related
run v8's d8 command, prompt (No debugging symbols found in ./d8). after executing the command, exit the program.
here is a hint of the code.
➜ x64.debug git:(e47af00448) ✗ gdb ./d8 // this
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.6.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./d8...
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/async-hooks-wrapper.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-console.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-js.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-platforms.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-posix.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8-test.o': file time stamp mismatch.
warning: `/Users/didi/Desktop/source/test/v8/v8/out/x64.debug/obj/d8/d8.o': file time stamp mismatch.
(No debugging symbols found in ./d8)
expect
can be used normally.
d8 produced using the gm x64.release command
Release builds don't have debugging information. Try gm x64.debug.
That said, the error message you posted does mention .../out/x64.debug/obj/..., so it's not clear how you actually built. Are you maybe trying to force one build's debugging information into another build's GDB session? That isn't going to work.
file time stamp mismatch sounds like recompiling might fix it, have you tried that?
Also, the usual workflow is to remain in the main checkout directory, and invoke d8 as gdb -args out/x64.debug/d8 .... If that was the problem, the error would likely look different though.
Another shot in the dark: try LLDB, which may work better on MacOS.
I tried this command:
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceRGB -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/pdftopdfa.pdf /tmp/test/pdftopdfa.pdf
But I got this error:
Artifex Ghostscript 9.14: Can't find initialization file gs_init.ps.
I tried another command:
gs -dPDFA -dBATCH -dNOPAUSE -dUseCIEColor -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/23238input.xml_2.pdf 23238input.xml_2.pdf
But i got this error:
Artifex Ghostscript 9.14 (2014-03-26) Copyright (C) 2014 Artifex
Software, Inc. All rights reserved. This software comes with NO
WARRANTY: see the file PUBLIC for details. Can't find (or open)
initialization file (gs_std_e.ps) Unrecoverable error: undefined in
.uninstallpagedevice Operand stack: gs_std_e.ps gs_std_e.ps
gs_std_e.ps
Well firstly you are using an old version of Ghostscript, you should probably upgrade.
Secondly wherever you got it from, its non-standard because it has the PostScript resources stored on disk, the default is for them to be built into the binary as a ROM file system.
Finally it appears that the resources on disk are either missing or corrupted. You could search for them, they are usually in somewhere like /usr/local/bin/ghostpdl/Resource and then use the -I switch to present that path to Ghostscript so it knows where to look.
But since its an old version then I'd suggest you get the current version (9.21) instead. If you get a package, and that fails to work, then you should complain to the package maintainer. If you feel up to it you can simply clone the Ghostscript Git repository and build it yourself, its not hard if you have a working C compiler (gcc). Lastly, there are pre-built Linux binaries here which may work on your system, depending on what your setup is.
A couple of notes on your command line; you have not specified the PDFA_def.ps file which you will have to do in order to create a valid PDF/A file, see this documentation but note that's the current 9.21 docs. If you don't supply that file (properly modified from the supplied model) then you won't be able to create a conforming PDF/A file.
Do not use -dUseCIEColor unless you have a very good reason, if you don't know what it does (and I'm guessing you don't) then you don't have a good reason. If you use it without understanding you'll only adversely impact performance and possibly get poor colour reproduction.
I would like to run my unit test suite with -fsanitize=address,undefined and have all sanitizer errors be written to a report.txt file. By default all sanitizer errors get written to stdout, however the software also writes info to stdout so this makes it difficult to detect errors. I tried:
export ASAN_OPTIONS="log_path=asan.log"
./mytests
And I also tried calling the C API before running tests:
#include <sanitizer/asan_interface.h>
__sanitizer_set_report_path("/tmp/asan.log")
However neither seems to work, all errors just get written to stdout. I am using Debian testing:
root#94e239ad460a:~# gcc --version
gcc (Debian 6.1.1-11) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
Is there any alternative method that I can save the sanitizer error from my unit tests somewhere?
Hm, I've successfully used log_path numerous times. If it does not work for you, please report a bug to ASan github (preferably with a minimal repro).
I realize that my binaries were not having read permissions. A simple chmod 500 <exe_path> solved my problem.
What I always do is to make sure the directory exists.
You could use Qt:
QDir().mkpath("/tmp");
Asan will append a PID to your filename though, and I don't think you can disable that.
In my common_interface_defs.h there is only __sanitizer_set_report_path but I see that gcc's master has a more recent function where you pass on a file descriptor:
void __sanitizer_set_report_fd(void *fd);
You could check out if your platform's gcc/clang has the newer function to set a file descriptor.
I'm struggling to get the pretty prints as described here in gdb working on my mac. I downloaded the latest gdb through macports and using gcc-4.8.
I loaded the ~/.gdbinit file and the printers are registered, but whenever I call
print myVector it gives me the raw output.
Any suggestions what I could do? Thanks a lot guys!
To have pretty printer with libc++ (new library used in Clang++/LLVM) use this new pretty printer:
https://github.com/koutheir/libcxx-pretty-printers
The .gdbinit is almost the same (see sample)
I've just tried with Eclipse Luna on OS X 10.10 and it works.
Any suggestions what I could do?
You can try to register pretty printers directly from gdb command line, bypassing .gdbinit file to narrow down the problem:
ks#ks-comp:~$ gdb -n
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python
>import sys
>sys.path.insert(0, '/home/ks/stlPrettyPrinter')
>from libstdcxx.v6.printers import register_libstdcxx_printers
>register_libstdcxx_printers (None)
>end
(gdb)
Note, that I've checked out pretty printers in /home/ks/stlPrettyPrinter folder:
ks#ks-comp:~$ ls -a /home/ks/stlPrettyPrinter
. .. hook.in index.html libstdcxx Makefile.am Makefile.in patch.txt .svn
ks#ks-comp:~$
If you're using the STL implementation in libc++ (the default with clang), GDB won't know how to pretty print the STL containers
Switch to using GNU libstdc++, and STL pretty printing in gdb should work.
STL pretty printers are implemented as Python programs that know about the implementation details of the STL containers and are maintained along with the STL implementations.
libc++ does not ship STL pretty printers that confirm to the GDB Python pretty printer API
Since you got your gcc-4.8 from MacPorts and MacPorts: Using the Right Compiler claims that gcc-* defaults to libstdc++ you should just avoid passing the -stdlib= option when using gcc.
I'm rebuilding a flash loader utility for a TI chip and am facing a minor issue that's affecting my workflow. I'm using a 64-bit Win7 PC and rebuilding the utility using make on cygwin bash shell. make and cygwin version numbers below.
$ make -v
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
CYGWIN_NT-6.1-WOW64 DEEDAA 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
One step in the build process calls a previously generated utility (windows executable) to generate the bin file that is required for the TI processor.
../../AISUtils//HexAIS_OMAP-L138.exe -ini ../sft_hexais.ini -o ../sft_C6748_SPI_MEM.bin ../sft_C6748_SPI_MEM.out
After this command is called there is no progress seen on the cygwin command line. However, execution of the command does complete, generating the files specified in this step and proceeds with the steps that follow in the makefile. It's just that I can never regain control of this window. I always need to kill the window, start another instance of cygwin.
If I try to kill the cygwin window immediately I get the message below.
mintty
Processes are running in session
Close anyway?
If I wait a while (the time to complete the steps that follow), then I can kill the window without this message popping up.
The same command on the windows command line is executed without any stalls and I do regain my command line.
c:\ti\boot_tools\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU\AISUtils>HexAIS_OMAP-L138.exe -ini ..\sft\sft_hexais.ini
-o ..\sft\sft_C6748_SPI_MEM.bin ..\sft\sft_C6748_SPI_MEM.out
-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------
Begining the AIS file generation.
AIS file being generated for bootmode: UART.
Parsing the input object file, ..\sft\sft_C6748_SPI_MEM.out.
AIS file generation was successful.
Wrote 15464 bytes to file ..\sft\sft_C6748_SPI_MEM.bin.
Conversion is complete.
It seems to me that something about the way the command is constructed is pushing commands on to another shell or forcing it to run in the background. Any thoughts on what may be going on or steps I can try to debug the issue?
file format of the executable that stalls
$ file AISUtils/HexAIS_OMAP-L138.exe
AISUtils/HexAIS_OMAP-L138.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Link to TI wiki that explains the build process. The link provides general instructions on rebuilding the utility and is very unlikely to provide any specific information related to my question. I'm only including it in case someone needed more background about the tools or the process.
http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package
Thanks.
Running Windows console applications inside a Cygwin (MinTTY) terminal is usually a terrible idea.
Try running inside a Windows (cmd) console or using cygstart to launch in a new window (in a Makefile, -w would probably be useful too).