What configure options a should use to compile mpich2 (ver 1.1.1p1 or 1.2.1p1) with sctp ?
In my try there is a error when linking cpi.c (small example).
/home/op02/mpiopt/sctp/lib/libmpich.a(ch3u_rma_sync.o)(.text+0x20a7): In functio
n `MPIDI_Win_post':
: undefined reference to `PMPI_Group_translate_ranks'
/home/op02/mpiopt/sctp/lib/libmpich.a(ch3u_rma_sync.o)(.text+0x21bd): In functio
n `MPIDI_Win_post':
: undefined reference to `PMPI_Group_free'
/home/op02/mpiopt/sctp/lib/libmpich.a(ch3u_rma_sync.o)(.text+0x25c4): In functio
n `MPIDI_Win_complete':
: undefined reference to `PMPI_Group_translate_ranks'
....
My options was
../mpich2-1.1.1p1/configure --enable-fast=O1 \
--host=x86_64-unknown-linux-gnu \
--target=x86_64-secret-linux-gnu \
--with-device=ch3:sctp --with-pm=hydra \
--with-cross=x8664secret.cross --disable-f77 --disable-f90 \
>conf.log 2>&1
with x8664secret.cross being an output of getcross.c program. Host, target, and this file are here to force a cross-compilation. (it is a requirement for this build)
Is sctp in mpich2 in active state and can it be compiled?
Does sctp network module support cross-building?
Try 1.3.1 instead. I see that Brad Penoff committed a couple of small changes to the build system since 1.2.1p1 was released, so it may be in better shape now. Alternatively, try using (the rather old) MPICH2 1.0.8, where I believe things were still working.
If the cross-compile step is what's really causing the problem and you still need to solve this problem, you can get more interactive support from mpich-discuss#lists.anl.gov. We can dig in over there instead.
Related
I want to compile Chromium for windows with different patches from different projects for myself (at least for today). I follow this official instruction:
https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md
All steps successfully passed, but i get awful low perfomance. In speeDOMeter benchmark (https://browserbench.org/Speedometer2.0/) my build get only 5 points, while official build get 116! This is commands for GIT what i use:
gclient
mkdir chromium && cd chromium
fetch --no-history chromium
cd src
gn gen --ide=vs out/Default "--args=target_cpu=\"x86\""
autoninja -C out/Default chrome -j 6
What i was try and this is not help:
Delete depot tools folder, and start over
Decrease -j from 10 to 8 and to 6
Delete argument --ide=vs
Fetch with history
Use command "gn gen" without --args part
Disable windows defender & firewall
As Asesh correctly noted, the problem was in debug mode. But adding key "is_debug=false" to gn gen command is not enough. The best solution will be the adding "is_official_build=true" key. Here is description:
is_official_build
Current value (from the default) = false
From //build/config/BUILDCONFIG.gn:136
Set to enable the official build level of optimization. This has nothing
to do with branding, but enables an additional level of optimization above
release (!is_debug). This might be better expressed as a tri-state
(debug, release, official) but for historical reasons there are two
separate flags.
IMPORTANT NOTE: (!is_debug) is *not* sufficient to get satisfying
performance. In particular, DCHECK()s are still enabled for release builds,
which can halve overall performance, and do increase memory usage. Always
set "is_official_build" to true for any build intended to ship to end-users.
Thanks Asesh for pointing me in the right direction.
I'm trying to run current Cobalt trunk (12.81256) on Ubuntu 16.04. but it fails:
[0814/100203:FATAL:graphics_system.cc(130)] Check failed: 1 == num_configs (1 vs. 0)
base::debug::StackTrace::StackTrace() [0x1f6202d]
logging::LogMessage::~LogMessage() [0x1f5fe99]
cobalt::renderer::backend::GraphicsSystemEGL::GraphicsSystemEGL() [0x67e5bdd]
cobalt::renderer::backend::CreateDefaultGraphicsSystem() [0x67e549e]
cobalt::renderer::RendererModule::Resume() [0x67dbe65]
cobalt::renderer::RendererModule::RendererModule() [0x67db776]
cobalt::browser::BrowserModule::BrowserModule() [0x1ce38c3]
cobalt::browser::Application::Application() [0x1cb71a5]
cobalt::browser::ApplicationStarboard::ApplicationStarboard() [0x1cb09c7]
cobalt::browser::CreateApplication() [0x1cb072e]
(anonymous namespace)::StartApplication() [0x1caef05]
cobalt::wrap_main::BaseEventHandler<>() [0x1cae9af]
SbEventHandle [0x1cae225]
starboard::shared::starboard::Application::DispatchAndDelete() [0x214dc7e]
starboard::shared::starboard::Application::DispatchStart() [0x214c07e]
starboard::shared::starboard::Application::Run() [0x214b8b7]
main [0x2120f95]
<unknown> [0x7f864632f830]
_start [0x1bd6029]
_start [0x1bd6029]
I found that issue with EGL configuration comes from using:
EGL_BIND_TO_TEXTURE_RGBA, EGL_TRUE
Without it eglChooseConfig will return 1 configuration.
But then it will fail again, after call to
eglCreateWindowSurface()
in cobalt/renderer/backend/egl/display.cc
[0814/111151:FATAL:display.cc(53)] Check failed: 0x3000 == eglGetError() (12288 vs. 12297)
Since this is EGL_BAD_MATCH error, chosen EGL config is not good, but neither was the original one.
I tried with setting
'gl_type%': 'system_gles2',
in starboard/linux/shared/gyp_configuration.gypi, but results were the same.
Am I missing something?
Steps for reproduction of crash:
Build:
cobalt/build/gyp_cobalt -C debug linux-x64x11
ninja -C out/linux-x64x11_debug cobalt
Run:
./out/linux-x64x11_debug/cobalt
Is there maybe some dependency on EGL or GLES libraries?
Issue is related to which libEGL and libGLES libraries are used.
Following libraries were used on my system:
libEGL.so.1 => /usr/lib/nvidia-375/libEGL.so.1 (0x00007f66bbebc000)
libGLESv2.so.2 => /usr/lib/nvidia-375/libGLESv2.so.2 (0x00007f66bbcad000)
When using libraries from mesa:
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa-egl ./cobalt
Cobalt will start and work.
Thanks Daniel and Andrew for help.
I have followed step by step the tutorial to install Veins, but when I tried running the example scenario (final step) I ended up with the above error.
The whole error was:
Error in module (cModule) RSUExampleScenario (id=1) during network
setup: Class "Veins::ObstacleControl" not found -- perhaps its code
was not linked in, or the class wasn't registered with
Register_Class(), or in the case of modules and channels, with
Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true
configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645 Working directory:
C:/Users/user/src/veins-4.3/examples/veins Command line:
../../../omnetpp-4.6/bin/opp_run.exe -r 0 -n .;../../src/veins
--tkenv-image-path=../../images -l ../../src/veins omnetpp.ini
I don't think I have missed a step during the tutorial as I have tried it two times. I did not make any change in anything, I've just strictly followed the tutorial like a robot, so I cannot provide an MCVE with more details than the tutorial.
Here is what I'm using:
- Windows 7 Pro 64 bits
- SUMO 0.25.0 64 bits
All other steps of the tutorial successfully worked until the final step.
I assume this error occurs when running Veins via the OMNeT++ IDE. Or, if you have compiled it with GCC (The error does not happen if you use CLANG)
There are two ways to bypass this error:
Use the .run as executable from your examples directory, which calls veins/run and includes all the required libraries:
Use opp_run as executable and set dynamic libraries to the directory where libveins.so is located (usually src/veins)
PS: to answer #ChristopSommer questions: Veins::ObstacleControl appears in opp_run -l src/veins -h classes
This could be a solution too, but I never tested it: Compiler flags in Eclipse
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 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.