We use docker and so the source code is for linux code. However, we develop on Macs, and as a result go-guru-callers fails to work when run locally.
It complains with the error below but the error is because that property is linux specific:
/Users/uri/Documents/connect/src/connect/job/native.go:104:4: unknown field Pdeathsig in struct literal
and the code:
cmd.SysProcAttr = &syscall.SysProcAttr{
Pdeathsig: syscall.SIGKILL,
}
Any workarounds?
You can use build conditions to specify what code should be built on what OS and architecture, in order to separate out code that is platform-specific and avoid these kinds of compilation failures. See the go build documentation here.
Related
I am trying to create custom snapshot from some Javascript file. I was able to create a snapshot using the command
mksnapshot.exe snapshot11.js --startup_blob snap.bin
but when I was trying to create an Isolate with this snap.bin file I got this message
The Isolate is incompatible with the embedded blob. This is usually caused by incorrect usage of mksnapshot. When generating custom snapshots, embedders must ensure they pass the same flags as during the V8 build process (e.g.: --turbo-instruction-scheduling).
I am guessing that I need recreate the snapshot with the proper flags but I couldn't find which flags I need to use.
My args.gn
is_component_build=true
v8_static_library=false
is_official_build=false
is_debug=true
use_custom_libcxx=false
use_custom_libcxx_for_host=false
target_cpu="x64"
use_goma=false
v8_use_external_startup_data=false
v8_enable_i18n_support = false
symbol_level=2
v8_enable_fast_mksnapshot=true
Any lead will be helpful.
10x
You can invoke ninja with -v to have it print all the commands it executes; e.g. if you compile V8 with:
ninja -v -C out/... v8_monolith
then you'll find a line for the mksnapshot invocation in the output, and can copy the flags from there. (If you have already compiled V8, ninja will say "nothing to do"; in that case you can either clean out everything, or just delete snapshot_blob.bin and libv8_monolith.so.)
I think this is a more specific Yocto problem so therefore I'm trying Stack Overflow:
During my Petalinux 2017.1 build I get the following warnings for a few packages, all of them in the recipes-core:
The init-ifupdown:do_unpack sig is computed to be cad131d20f065f81a9524376bd7d40bc, but the sig is locked to f2c445306ecd0f9936cc1b9d35a0587e in SIGGEN_LOCKEDSIGS_t-cortexa9hf-neon
These scripts are mostly used to substitute config files like /etc/network/interfaces and such. It seems these config files are not changed, so I was wondering if this warning is related.
I did not have this problem in Petalinux 2016.4, so the recipes has been given a run through before.
To resolve this warning, add the following line in plnx_proj/project-spec/meta-user/conf/petlinuxbsp.conf:
SIGGEN_UNLOCKED_RECIPES += "init-ifupdown"
I am trying to play a wav file in a very simple program that looks like this, currently attempting to use nim-csfml:
import csfml_audio
var alarmsong = newMusic("alarm.wav")
alarmsong.play()
but it appears to be relying on the existence of libcsfml.audio, and while my program compiles just fine, when I try to actually run it I get an error
| => ./alarm
could not load: libcsfml-audio.so
(I have a libcsfml-audio.dylib instead, being that I used the OSX shared libraries for csfml/sfml)
Is there some other way to play a .wav file in Nim?
Edit 1:
After the PR made by #def-, I now get a different, slightly more comforting error, which is probably due to some poor understanding of how nim deals with shared libraries:
| => ./alarm
could not load: libcsfml-audio.dylib
I added path = "/usr/local/lib" to my nim.cfg file, but it didn't seem to be affect anything. I also exported $LD_LIBRARY_PATH="/usr/local/lib" (/usr/local/bin is where libcsfml-audio.dylib is.), and tried compilation through
nim c alarm.nim --clib:/usr/local/lib/libcsfml-audio.dylib
Thanks for the help!
This program would just exit immediately; you need to keep it alive while the sound plays. Append this to the program:
import csfml_system
while alarmsong.status == SoundStatus.Playing:
sleep 100.milliseconds
For nim-csfml to work you'll need SFML 2.1 and CSFML 2.1. Also, it seems that nim-csfml is actually broken for Mac OS X, so I've made a pull request with a fix: https://github.com/BlaXpirit/nim-csfml/pull/4
Other modules that could play sound are sdl_mixer, sdl2/audio and allegro5.
As an OSX-only alternative without using any libraries, by calling the afplay binary:
import osproc
discard execProcess("afplay", ["file.wav"])
Edit1:
When Nim reports "could not load: libcsfml-audio.dynlib" that could also mean that one of the dependencies of that library are missing or in a wrong version. Especially SFML 2.2 doesn't work with CSFML 2.1. Make sure libsfml-audio.dynlib is in your LD_LIBRARY_PATH as well. If that doesn't work either, you could try to compile and run a regular C CSFML example like this one: https://gist.github.com/def-/fee8bb041719337c8812
Compile it with clang -o mainpage -lcsfml-graphics -lcsfml-audio -lGL -lGLEW mainpage.c to see the errors/warnings about missing libraries.
I use GTK3 , codeblcks IDE, glade3 in windows 7...
In my application i have a button which when clicked should open a gtk_file_chooser_dialog...
But gives the fillowing error..
Glib-GIO-ERROR**:No GSettings schemas are installed on the system
static void on_save_clicked(GtkWidget *widget,gpointer data)
{
GtkWidget *dialog;
//dialog=gtk_file_chooser_dialog_new("Save it",GTK_WINDOW(gtk_builder_get_object(builder,"mainwindow")),GTK_FILE_CHOOSER_ACTION_SAVE,GTK_STOCK_OK,GTK_RESPONSE_OK,GTK_STOCK_CANCEL,GTK_RESPONSE_CANCEL);
//dialog=GTK_FILE_CHOOSER_DIALOG(gtk_builder_get_object(builder,"filechooserdialog"));
gtk_widget_show_all(dialog);
gint resp=gtk_dialog_run(GTK_DIALOG(dialog));
if(resp==GTK_RESPONSE_OK)
g_print("%s\n",gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog)));
}
I use g_signal_connect(...) to call this function when the button is clicked...
I cannot understand the problem...
I got the very same error when trying to open a FileChooserDialog.
(lancer_ihm.py:1047004): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup: assertion 'source != NULL' failed
(lancer_ihm.py:1047004): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
Trace/breakpoint trap (core dumped)
I 'm running a Gtk3 interface with python3 on Linux.
Gtk3 and all its dependencies were installed from the sources.
I found the solution on this forum http://forum.tinycorelinux.net/index.php?topic=13699.0
I just set XDG_DATA_DIRS variable with the path to where the gtk schema files are located and it works.
$ ls /home/user1/ctcils/dusserm/applications/gtk/3.12.1/share/glib-2.0/schemas/
gschemas.compiled org.gtk.exampleapp.gschema.xml org.gtk.Settings.FileChooser.gschema.xml
org.gtk.Demo.gschema.xml org.gtk.Settings.ColorChooser.gschema.xml
$ export XDG_DATA_DIRS=/Produits/publics/x86_64.Linux.RH6/glib/2.40.0/share/:/home/user1/ctcils/dusserm/applications/gtk/3.12.1/share/
There are probably few errors in there.
If you commented both, the dialog.show_all () will produce error because, it hasn't been instantiate yet you asked to be shown.
If you use the first one, object Gtk.FileChooserDialog param has to end with NULL (in c), read the doc
If you use the second one, check your glade signal property in your glade window
Check your gtk installation
Quoting from this StackOverflow answer,
Seems you're not the one having this problem, and it also happens on Windows on MinGW. Luckily, that person gave a solution:
The thing, as it seems as I was running the test-widget example (that I
built with gtksourceview-3.0.0 using MSVC), was that I need to compile the
org.gtk.Settings.FileChooser.gschema.xml file (from GTK+-3.x, under
$(srcroot)/gtk) with the glib-compile-schemas utility that is from GLib,
which will generate gschemas.compiled in the same folder.
After that, place that gschemas.compiled file in the this folder:
$(parent_folder_of_the_gtk3_dll)\share\glib-2.0\schemas
and one will be set to use the gtkfilechooser without the puzzling
[GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser'
is not installed] error.
I will add to my GLib project files to compile the glib-compile-schemas
utility and add to my GTK+-3.x project files to compile the
the org.gtk.Settings.FileChooser.gschema.xml shortly.
I m using gdb on a aix shared lib running on aix 5.3?
When i try to run gdb for this file
i get a error message saying ""Architecture of file not recognized"
Don't know how to get this fixed.
Does anybody know why i get this message ""Architecture of file not recognized"?.
gdb runs fine on other executables compiled by xlc.
Is there some option that i might have used while compiling , which is not compatible with GDB.some processor specific option.
I compiled the shared lib w xlc v9.0 for aix.
Thanks.
You don't run GDB on a shared library, you run it on an executable.
If the executable loads your shared library, GDB will know about it.
void
set_gdbarch_from_file (bfd *abfd)
{
struct gdbarch_info info;
struct gdbarch *gdbarch;
gdbarch_info_init (&info);
info.abfd = abfd;
info.target_desc = target_current_description ();
gdbarch = gdbarch_find_by_info (info);
if (gdbarch == NULL)
error (_("Architecture of file not recognized."));
deprecated_current_gdbarch_select_hack (gdbarch);
}
This is the actual GDB code in question (gdb/arch-utils.c:530-544).
The information passed to the gdbarch pointer seems to be invalid. This is caused by gdb_find_by_info returning a NULL pointer and that is caused by find_arch_by_info (gdb/gdbarch.c:3656) returning a NULL pointer.
It basically means what it says: GDB could not identify the architecture of the file. This seems to be a common problem for xlc, even on recent gdb versions.
XLC and gdb are, as far i remember and understand, not very good when it comes down to compatability terms (AIX support is minimal), you might try using the Gnu C Compiler .You might look at the GDB sources for VERY specific information (that i can't really give you).
Here is a link to gcc-AIX specifics.