My old FOSS project
https://akrobiz.com/ezfb/
used to compile just fine, but that was in 2016.
Now I get multiple function definitions in the linker.
I realize I have to also add -lm to the link command for the math.
To run the demos, you need a frame buffer enabled kernel.
To compile you need fb.h.
It's good to have fbset installed and have a display device that is not running X.
TIA!
James.
Related
In the past, Ghostscript used to incorporate these Apple Imagewriter devices: iwhi, iwlo, and iwlq. The version I had been using is gs 8.7 which is not 64-bit compliant. macOS Catalina cannot use it or any other 32 bit code, so printing to those devices fails.
More recent versions including the most recent Ghostscript 9.27 omit those devices. I don't know when they were omitted or why but it seems to be a while ago. Worse, I don't know how they get incorporated in Ghostscript. Other than building gs from its source code, which I have done, I don't know where to begin. The new Ghostscript 9.27 itself works fine in macOS Catalina. It includes many "built-in" devices but the ImageWriter devices I need are absent.
The drivers and Ghostscript were originally obtained from the Linux Foundation's Open Printing website: https://openprinting.org/printer/Apple/Apple-ImageWriter_II, but they were bundled and distributed in a package form that recent macOS versions cannot handle. That web page also indicates the drivers are "Type: Ghostscript built-in" which it no longer is in recent versions.
Here is gs -h using the installed 32 bit version:
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
alc1900 <snip> inferno iwhi iwlo iwlq jetp3852 jj100 <many other devices> <snip>
Search path:
. : %rom%Resource/Init/ : %rom%lib/ :
/usr/local/share/ghostscript/8.71/Resource/Init :
/usr/local/share/ghostscript/8.71/lib :
/usr/local/share/ghostscript/8.71/Resource/Font :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
/usr/share/cups/fonts
Initialization files are compiled into the executable.
For more information, see /usr/local/share/ghostscript/8.71/doc/Use.htm.
Please report bugs to bugs.ghostscript.com.
iMac4:ghostscript-9.27 john$
The obvious sticking point is right there in front of me: "Initialization files are compiled into the executable." I know that, but what initialization files (if any) need to be included or modified to ensure their incorporation in the build? I have printer PPDs for the ImageWriter. They're just text files, and I think they would be required. Should they? How?
The only way I have attempted to build gs from source is to use ./configure followed by make That begins a long compilation process that takes a few minutes, and results in an executable gs that works fine in Catalina. The problem is it does not include the drivers I want. Attempting to print to that printer results in it printing "Unknown device: iwhi" in straight ASCII text (not bitmapped).
By now it ought to be painfully obvious I'm well over my head and don't know where to turn. Can anyone point me in the right direction from here?
Some background can be found here: Apple ImageWriter printer installation in… - Apple Community
. I wrote it. Some of its links are dead. If a picture doesn't load and you want to see it, click on it (it's a site problem).
A recent Discussion describing this dilemma is here: 32-bit ghostscript, required for ImageWriter and other printers using CUPS
The devices quoted were removed in this commit If you need them then you should be able to :
Clone our git repository, help on this is here
git checkout a87e380acd5e326f7d4e4380348bac393fac3058
copy the ghostpdl/devices/gdevadmp.c file somewhere convenient
git checkout master (or if you want a tagged release rather than the bleeding-edge code, git checkout ghostpdl-9.27 for example)
copy the saved file back to ghostpdl/devices/gdevadmp.c
Undo the changes in contrib.mak, configure.ac and unix-gcc.mak
(using the link to the gitweb you can see the diffs, they are not
extensive)
In the ghostpdl directory: ./autogen.sh then make
That all assumes you have a working C compiler (gcc, make etc) and development environment, but you say you've already built GS from source so that should be fine. The end result should be a woking Ghostscript with the additional device built in.
This:
Initialization files are compiled into the executable.
refers to the PostScript initialisation files, and won't help you with devices which are written in C and have to be compiled. While the line above is technically correct, you can use the -I switch to override the ROM file syatem (which is what that refers to) and have the initialisation files stored on disk instead.
PPD files aren't going to help you with Ghostscript, these are PostScript Printer Description files and they are used by applications which generate PostScript to customise the PostScript program for the specific printer. These are (I think) used by CUPS, but not by Ghostscript.
I think THIS is the commit to remove gdevadmp.
I think this was removed in a flurry of activity removing stuff referred to as "moribund" MacOS and classic Mac stuff, and I think this specific removal was unwarranted and unwise, as these drivers are still in use today Using foomatic-rip:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a87e380acd5e326f7d4e4380348bac393fac3058
I am another Mac User and ImageWriter and ImageWriterLQ owner, I do not speak for Artifex.
at version 9.05, the file gdevadmp containing appledmp, iwhi, and iwlo, and iwlq was MOVED into the 'devices' folder. It survived there until version 9.20.
After version 9.20 it was removed in an operation that included only gdevadmp and its supporting files. The note does not say WHY it was removed.
So a 64-bit build of ghostscript 9.20 has some potential.
The files available at:
https://wiki.linuxfoundation.org/openprinting/macosx/foomatic#ghostscript_for_mac_os_x_103x_panther_-_mac_os_x_109x_mavericks
are still good, but gs and the filters need to be moved to a directory that remains accessible after the lockdown of sandboxing (about Mavericks) Suggested directory is noted in the apple support community discussion you posted earlier.
Links on the Ghostscript web site say that THIS (StackOverflow) is the official forum for discussing issues related to Ghostscript.
If that is not appropriate, what do Artifex and Ghostscript developers suggest is the "official" forum for Ghostscript issues?
I stumbled across this thread while working on a shelter-in-place project to resurrect my ImageWriter II by building Ghostscript and cups-filters for Catalina. My solution isn’t quite there yet; I can get 75% of the CUPS printer test page printed before silently crashing.
The solution for defeating sandboxing is to compile Ghostscript with dynamic linking disabled. Otherwise, even if you move the gs executable into a sandbox blessed location, the gs process will get killed as soon as it tries to link in the drivers. From my notes:
Download Ghostscript 9.20, the last gs with the Apple dot matrix drivers: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs920
Build Ghostscript with the drivers statically linked in (otherwise sandboxing gets you): ./configure --disable-dbus --disable-dynamic --disable-gtk --with-drivers=APPLE,PS --prefix=/usr/local/ghostscript-9.20
I have not yet tried to forward-port the iwhi drivers and such into the Ghostscript; that’s my next task, in the hope that it fixes the silent crash.
I am new to Ubuntu and searched on-line for two days, tried a lot of solutions but do not have any luck yet. If anyone can help with this, I will appreciate.
I wrote a program in Java with eclipse on Windows. My program makes use of Java hidapi library, which is a Java wrapper of the C version hidapi library (.dll). In eclipse, by adding the Java hidapi to the build path and setting the C hidapi as a native library, everything works just fine.
Now I want to do the same on Ubuntu. The same Java hidapi is used, which now will make use of the C version hidapi library for Linux (a .so file). When making the C version hidapi library for Linux, it turns out that I need another library called libusb-1.0 (which hidapi needs to deals with the low level communication). So I install libusb-1.0 (now I have a libusb-1.0.so file under /usr/lib/i386-linux-gnu), make the C version hidapi library for Linux. I have a small C program and I test it under bash, it works so I believe until this point everything, both libsub-1.0.so and C version hidapi library for Linux libhidapi-jni.so are installed/generated correctly, and when running the small C program the system is able to find the shared libusb-1.0.so library without explicitly mentioning where libsub-1.0 is (which makes sense because libusb-1.0 is installed in a place where the system loader will always search).
So I go to eclipse. I import the eclipse work space, add the Java hidapi to the build path (as I did in Windows), move the C version hidapi library for Linux (the .so file) into a folder called 'lib' (where the .dll version of native library also resides). And I set the native library to 'lib', by "build path" -> "configure build path" -> "libraries" tab -> "native library location". So till this point, the two native libraries are: libusb-1.0 under /usr/lib/i386-linux-gnu, and hidapi.so under 'wherever eclipse workspace is'/lib. Finally in the source code I add two lines:
System.loadLibrary("usb-1.0"); // Call this line A.
System.loadLibrary("hidapi-jni"); // Call this line B.
I run the program as a Java application. It reports "java.lang.UnsatisfiedLinkError: no usb-1.0 in java.library.path" at line A. So I guess the Java runtime is not able to find where libsub-1.0 is.
Just for clarification, I already did the following trials, none of them worked.
Remain the two libraries where they are, add vm argument (Run -> Run Configuration -> Arguments -> VM arguments): -Djava.library.path="${workspace_loc:project_name}/lib;
/usr/lib/i386-linux-gnu". It gives: "java.lang.UnsatisfiedLinkError: no usb-1.0 in java.library.path" at line A.
Undo 1. Move libsub-1.0.so to 'wherever eclipse workspace is'/lib, so now the two .so files are together. Set .jar's native library location to this folder. It gives "java.lang.UnsatisfiedLinkError: blablabla: undefined symbol: libusb_control_transfer" at line B. So I think it founds the libusb library, however the symbol (which should be in libusb) is still unresolved. This is really weird.
Can anyone help me? Thanks in advance.
i am using scons for different compilers.
vc10 and renesas compiler.
if i compile the program by using env.program(---) am getting the link flags as
"link /nologo /subsystem:console /pdb:project.pdb /OUT:program.exe D:\build1\subdirA\subdirA.lib D:\build1\subdirB\subdirB.lib main.obj"
it is working for VC10 compiler. But for renesas(my microcontroller) compiler, i am getting an error like
"Cannot open file : "/OUT:program.exe""
it will accept " -output=program.abs" command when linking. how can i change that one. can you please tell me
when program is linking /OUT:program.exe is adding by default.
can you please tell me how to change that to "-output=program.abs"
Thank you
What you want to do is called cross-compile: compile a Renesas binary on Windows. Seems like what you have done is loaded the Windows VC10 toolset in SCons (SCons does this automatically unless told not to) and just changed the compiler binary, so SCons is still using the VC10 compiler/linker flags, which dont seem to be compatible. I had to do something similar once with SCons, where I cross-compiled Cavium Octeon in a Linux environment, but luckily for me almost all of the flags were compatible.
I dont know anything about Renesas, but if its compilation flags are more similar to another platform/toolset, then load those instead of Windows, as follows where Im loading the Linux gcc toolset.
env = Environment(tools = ['gcc'])
Look for Construction Environments in the SCons man page for a complete list of supported tools. Keep in mind that by doing this, you will no longer have support for the native platform toolset, Windows VC10 in your case.
When and if you find a similar platform, and you still need to change some compiler/linker flags or options, take a look at changing the related SCons Construction Variables. A few that could be helpful are: CXXFLAGS, LIBSUFFIX, LINKFLAGS, OBJSUFFIX, and PROGSUFFIX. The LINKFLAGS construction variable is actually the answer to your original question.
I did a google search for scons renesas, and came across this link which might also be helpful.
I've been using Libpng15 in Windows 7, but I've been getting errors in relation to the
Unresolved External _png_set_longjmp_fn error when I compile my code. I followed the directions in the aforementioned link, and while it DID compile without any errors, I wound up with a message saying that I needed libpng12.dll to continue.
So, I did some Googling for libpng12.dll...nothing came up but generic "find x.dll" websites which appeared to be scams.
I've tried reading the INSTALL docs for the libpng source code on their website, and all that I see is instructions on how to do it via Unix based systems. I tried to do this in Cygwin with no luck, so I'm kind of stuck on how to compile this library.
All in all, I'm willing to do either the compilation or just using the .dll, though the problem is that I can't find a working .dll for version 12.
Another thing I tried was downloading binaries from here, which claimed to be "libpng12 for windows". I then copied the files into my VC compiler directory, which overrode libpng15, I think. Still, when I link against it statically and run my program in VC, it says that I require the .DLL file. The libpng12.dll file was in fact a .dll.a file instead. I honestly am not sure to link these (I tried linking it statically by typing "libpng12.dll.a" in the Linker Input setting through VS).
If I can go the .dll route for libpng12, how do I do this? Where is the file? How do I link it in VS?
Any help would be appreciated, as it seems there really isn't a whole lot of information on this. Either that, or I'm just not looking properly.
Look in the "projects" directory of the libpng distribution, and use one of the visual projects.
As mentioned above Look in the "projects" directory of the libpng distribution
Then make the adjustments outlined here
https://stackoverflow.com/a/38547948/293792
Which I note here for simplicities sake
(as stated there) adding two lib values to
Config -> Linker -> Input -> Additional Dependencies
these values are ucrt.lib;vcruntime.lib
Ensuring the build type is /MD
Allowed me to build these older versions, and fix that error on Windows 10 VS2015.
This link seems to have an installer for 1.2 for you:
http://gnuwin32.sourceforge.net/packages/libpng.htm
it's 32 bit. Not sure if that makes a difference for you.
Is it possible to run GDB with a program assembled with as and linked with ld? With gcc adding the flag -g allows for debugging but I get the error No symbol table is loaded. Use the "file" command when I try to add breakpoints to a loaded program.
Thanks!
EDIT Maybe I should make it clear that I'm learning and programming in assembly. All I really want is a stack trace but being able to use GDB would be great.
Resolution Running as -g does the trick.
Thank you to all that answered!!
It is possible. However, you need symbols in order to add symbolic breakpoints, and symbols are provided by debugging info; make sure your assembler and linker are providing those. EDIT With GNU as, use as -g. Or just use gcc -g: if you give it a .s file, it will invoke the assembler and linker as appropriate.
GDB understands debugging info in several formats: stabs, COFF, PE, DWARF, SOM. (Some of these are executable formats with debugging sections, others are debug info formats that can be embedded into executables, such as ELF.) gcc -g usually chooses whatever the platform's default is, gcc -ggdb usually chooses the most expressive (depending on your versions, possibly DWARF-3).
If you have debugging info embedded into or linked to by the executable, gdb will try to load it automatically. If you have it elsewhere, you may need to use file to tell gdb where to find it.
You can still debug without symbolic information. For example, you can issue break *0x89abcdef to insert a breakpoint at that address, if there's any code there.
you could try running as with the --gdwarf-2 or -g options, and make sure ld is not called with --strip-debug, and that your makefile/install process is not stripping the executable.
That's not an error preventing debugging, that's an error setting breakpoints in the way you are trying to do it. Since GDB doesn't have any symbol information, you'll have to set the breakpoints some other way.
If you don't have a symbol table, then you can't set breakpoints symbolically (by function name, line of code, etc). You could still set a breakpoint for a specific address, if you know the address you are trying to stop at.
gdb> b 0x12345678
Of course that's only useful if you know that you want to stop at 0x12345678
What does file say about your executable?