I just compiled my own version of gcc/9.2.0 using gcc/4.8.2. After successful compilation and installation of gcc/9.2.0 I try compiling ucx-1.5.1. When I try to run the ucx configure script I get the following message "checking attribute((constructor))... configure: error: Cannot continue. Please use compiler that supports attribute((constructor))".
When I run the script using the old gcc/4.8.2 I get no error at all.
Any idea what went wrong?
Any idea what went wrong?
No.
You can have a look at the respective config.log file, it usually contains additional information. In general, not every compilation error during configue indicates a problem, it's usually just feature test that just revealed a specific feature is not available.
Ucx uses next code to determine support of attribute __attribute__((constructor)). You can test it by yourself:
gcc -x c - <<EOF
static int rc = 1;
static void constructor_test() __attribute__((constructor));
static void constructor_test() { rc = 0; }
int main() { return rc; }
EOF
And post here if you have some errors.
I had the same problem, because I installed a software named "binutils-devel" on CentOS 8.4.
When "binutils-devel" was removed, the compile of ucx was successful.
Related
I'm trying to compile project with emcc using gradle and so far failing to find any decent example of how it can be done (or to learn to to it on my own).
What I've tried to do so far is to set path to clang this way:
model {
toolChains {
clang(Clang) {
path "<path-to-emcc>"
}
}
...
}
I'm getting a "Could not find C compiler 'clang'." message.
Next thing I've tried is to create a clang symlink to emcc, but, again, failed miserably.
Were you able to find a solution for this?
I am having the same exact problem and, after looking around in the Gradle source code, this seems to be an issue specific to running the build on Windows:
ToolSearchPath.java:
private File findExecutable(OperatingSystem operatingSystem, String name) {
List<File> path = pathEntries.isEmpty() ? operatingSystem.getPath() : pathEntries;
String exeName = operatingSystem.getExecutableName(name);
try {
if (name.contains(File.separator)) {
return maybeResolveFile(operatingSystem, new File(name), new File(exeName));
}
for (File pathEntry : path) {
File resolved = maybeResolveFile(operatingSystem, new File(pathEntry, name), new File(pathEntry, exeName));
Because of the String exeName = operatingSystem.getExecutableName(name); line, Gradle is actually looking for emcc.exe instead of emcc.bat.
Update # 2020-07-14
I was able to get around above problem by making these changes.
But now I am stuck with following issue which is much harder to tackle:
> Task :linkDebug FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':linkDebug'.
> java.lang.NullPointerException (no error message)
After debugging Gradle's own code, I was able to determine that this issue is caused by emlink.py not handling special -dM -E -v arguments combination when Gradle's GccMetadataProvider probes it with these arguments in order to determine linker version.
I'm trying to build a project, using the DMD-compiler itself (without IDE) in Windows. And I found myself hardly capable to realise some moments about linking. Usually the IDE does this for me.
The structure of my project
project
├──bin
| ├──exemple.obj
| └──exemple.exe
└──src
├──a
| └──b.d
└──exemple.d
exemple.d
import a.b;
void main() { B obg = new B(); }
b.d
module a.b;
class B {
private int i;
public this() {i=0;}
public void act() {i++;}
}
At first it seemed to be easy to build with command:
cd C:\path\to\my\project
dmd bin\exemple.exe src\exemple.d -IC:\path\to\my\project\src
But it only showed me some error-massages:
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bin\exemple.obj(exemple)
Error 42: Symbol Undefined _D1a1b1B7__ClassZ
bin\exemple.obj(exemple)
Error 42: Symbol Undefined _D1a1b1B6__ctorMFZC1a1b1B
--- errorlevel 2
Finally I guessed that the obj-file was missing. I made it manually with commands:
cd bin
dmd ..\src\a\b.d -c
cd ..
And manually added it to my build-command:
dmd bin\exemple.exe src\exemple.d -IC:\path\to\my\project\src bin\b.obj
And now it works.
Great. But what if we've got lots of additional d-files and complicated folders structure?
How could it be atomised?
I was strongly surprised, when I found out that DMD doesn't doing all this automatically. Maybe, I'm just doing it wrong.
You don't have to build a/b.d separately. But you do have to pass all source (or object) files to dmd. dmd does not figure out the dependencies.
Have a look at rdmd. It's a tool that does figure out the dependencies and then runs dmd on all of them (and then it runs the executable by default, --build-only prevents that). It comes with the dmd releases.
I am in a HUGE depression now! I spend 2 days trying to use boost.python . PLEASE guide me! I will explain what I did.
I have Winows 7 64 bit.
The Python is 64 bit 2.7.3 installed at C:\Python27_amd64.
Now, I take boost_1_54_0.zip and unzip in F: directory.
The I use cmd.
bootstrap
this creates project-config.jam. I edit it and insert
using msvc : 9.0 ;
using python : 2.7 : C:\Python27_amd64\python : C:\Python27_amd64\include : C:\Python27_amd64\libs ;
Now i do
.\b2
This process runs for 20 something minutes and I am told that boost has successfully been build.
After that I install boost binaries from http://sourceforge.net/projects/boost/files/boost-binaries/
The binaries get installed in C:\local\boost_1_54_0.
Now I want to create a General project.
Now, I use the code given for embedding python in C++ here
#include <boost/python.hpp>
#include <boost/detail/lightweight_test.hpp>
#include <iostream>
namespace py = boost::python;
using namespace std;
int main()
{
// Initialize the interpreter
Py_Initialize();
py::object main_module = py::import("__main__");
py::object main_namespace = main_module.attr("__dict__");
py::exec("print 'Hello, world'", main_namespace);
py::exec("print 'Hello, world'[3:5]", main_namespace);
py::exec("print '.'.join(['1','2','3'])", main_namespace);
}
I setup the header files and library in VC++ directories to F:\boost_1_54_0\boost_1_54_0 and F:\boost_1_54_0\boost_1_54_0\stage\lib respectively.
I also setup project-->properties-->configuration properties-->C/C++-->General-->Additional Include directories to C:\Python27_amd64\include
Likewise, I also setup project-->properties-->configuration properties--> Linker--> General to C:\Python27_amd64\libs;"C:\local\boost_1_54_0\lib64-msvc-9.0" .
Now when I compile using x64 debugger. It gives me an error
Unhandled exception at 0x00000000 in test8.exe: 0xC0000005: Access violation at location 0x0000000000000000.
I am struck since last 2 days...but thats the closest I have been since then. please help me!
So you mean a runtime error, right?
I think you should first ensure, that there is no exception thrown by boost::python itself.
First try to set the try block around you python calls with a catch(...)
If exception is caught it is most probably the boost::python::error_already_set exception.
So, you then should decode it like here
I'm trying to create a shared library from Haskell source code.
I've tried following the instruction here: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I'm just not having any luck.
When I compile with Haskell 64-bit (ghc 7.0.4 from 2011.4.0.0) I get the following error:
ld: pointer in read-only segment not allowed in slidable image, used in
___gmpn_modexact_1c_odd
As an alternative I also tried the 32-bit version, and depending on the exact flags I use to link get errors such as:
Library not loaded: /usr/local/lib/ghc-7.0.4/base-4.3.1.0/libHSbase-4.3.1.0-ghc7.0.4.dylib
I did manage to get a little further by adding -lHSrts to the linker line. This got me to the point of successfully linking and loading the library, but I'm then unable to find the function name using dlsym (or manually using nm | grep)
Any hints would be greatly appreciated, an example make file, or build line that has successfully built (and used) a shared library on OS X would be appreciated. I'm quite new to Haskell and don't know if I should keep banging my head assuming that the problem is on my end, or for various reasons I shouldn't expect this to work on OS X.
A git repo with all the combinations I've tried is available here: https://github.com/bennoleslie/haskell-shared-example I did manage to get something working for 32-bit ghc, but not 64-bit yet.
It is possible to create working shared libraries on 64-bit OS X, with the latest Haskell Platform release (2012.4 64bit)
The invocation line works for me:
ghc -O2 --make \
-no-hs-main -optl '-shared' -optc '-DMODULE=Test' \
-o libTest.so Test.hs module_init.c
module_init.c should be something like:
#define CAT(a,b) XCAT(a,b)
#define XCAT(a,b) a ## b
#define STR(a) XSTR(a)
#define XSTR(a) #a
#include <HsFFI.h>
extern void CAT(__stginit_, MODULE)(void);
static void library_init(void) __attribute__((constructor));
static void library_init(void)
{
/* This seems to be a no-op, but it makes the GHCRTS envvar work. */
static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv;
static int argc = 1;
hs_init(&argc, &argv_);
hs_add_root(CAT(__stginit_, MODULE));
}
static void library_exit(void) __attribute__((destructor));
static void library_exit(void)
{
hs_exit();
}
This git repo: https://github.com/bennoleslie/haskell-shared-example contains a working example.
All credit goes to this original source: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/
You might want to try the ghc port in Homebrew -- https://github.com/mxcl/homebrew/blob/master/Library/Formula/ghc.rb
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.