On freebsd 12 the xwindows module in PolyML is not implemented so I am trying to compile its source outside the ports tree. It does compile, but I cannot open the XWindows module in poly.
What I did is:
copied libX11 to /usr/lib to be sure, and made symbolic links in
/usr/include for Xm and X11 to /usr/local/include.
inserted one space in xwindows.cpp because of a clang error
added these options to configure :
--x-includes=/usr/local/include/X11 --x-libraries=/usr/local/lib/ --with-x --with-system-libffi
set the environment : LDFLAGS=-L/usr/local/lib/gcc7 , where libstdc++
is located
tried with clang and gcc7
The code compiles without further errors. There is a file xwindows.o, 375160 bytes for cc and 291184 for gcc7.
The log contains
Created structure XWindows
Created structure Motif
I run poly from where it was compiled, and get
open XWindows
poly: : error: Structure (XWindows) has not been declared Found near open XWindows.
The non-graphics modules open normally
What am i doing wrong here ?? thanks for pointers
I
added CONFIGURE_ENV= LDFLAGS=-L/usr/local/lib to the port's Makefile, and
inserted a space before ZERO_X in xwindows.cpp
after which the ports code compiled, including the 2 modules in poly
My error has been to omit a make rmconfig before new compilation, and I had originally compiled poly without motif, so that kept coming back
Related
I am looking to edit and recompile the hcitool.c of bluez version 5.31. I installed the bluez 5.31 by following the procedure from the answer of this:
Bluetooth Low Energy in C - using Bluez to create a GATT server
In my trial, I duplicated the hcitool.c file and named it as myhcitool.c inside the tools folder and I use the command
gcc -o myhcitool.o myhcitool.c.
This gives me an error
myhcitool.c:43:27: fatal error: lib/bluetooth.h: No such file or directory
#include "lib/bluetooth.h"
^
compilation terminated.
I tried copying the myhcitool.c outside the tools folder and compile it there. That gave me a bunch of errors something like this:
/tmp/ccj1QmZK.o: In function `dev_info':
myhcitool.c:(.text+0x293): undefined reference to `ba2str'
/tmp/ccj1QmZK.o: In function `conn_list':
myhcitool.c:(.text+0x501): undefined reference to `ba2str'
myhcitool.c:(.text+0x50f): undefined reference to `hci_lmtostr'
myhcitool.c:(.text+0x586): undefined reference to `bt_free'
/tmp/ccj1QmZK.o: In function `cmd_dev':
I also tried editing the hcitool.c itself by modifying a simple printf in there and then redo the 'make' and 'make install' commands for the whole bluez. After that, when I tried running the hcitool, the modification that I did has no effect.
The compilation errors clearly state that you are missing files and directories and that there are undefined references to types (since you are missing the files). You are copying a file outside of its directory and trying to compile it. This won't work as the includes (and more) required for it to compile correctly are missing.
If you want to edit hcitool directly you should download the Bluez source, unpack it, cd into it and ./configure it. The makefile will be generated and you can use make to build the executables. If you make change to the hcitool.c file you should make sure you recompile it and are running it inside the directory as ./hcitool and not as general hcitool as this runs the executable installed to your system, rather than the one you edited.
If you want to build it outside of the Bluez directory as a sort of standalone, you will have to copy all the files and folders defined in the #include <x> statements that are needed and make a separate makefile for those, since copying the existing one will probably not work.
If you want to add a new file to the Bluez source, make sure you also make the correct Makefile edits so that it is included during compilation.
I'd like to add that hcitool has not been maintained for a long time and is on its way to being phased out of Bluez, so maybe you should take a different approach altogether!
I am trying to integrate a Matlab program I wrote into some Fortran code. I tried to follow the example Mathworks provides. But I can't get it to compile because I can't find the header files it requests.
Does anyone know of an example of someone getting it to work on Linux using an Intel compiler. I think that might be part of the problem because Matlab only supports GNU Fortran on Linux.
And I realize this is a simple question, I just don't understand how to do anything in compiling more complicated than including multiple files with defined paths.
Disclaimer: I'm currently using OS X so I can only provide output from OS X but everything should transfer easily over to Linux due to the Unix base. I also don't have the Intel Fortran compiler on OS X (only the C/C++ compiler).
Note: You will need to substitute the paths I use for the correct paths on your system depending on your MATLAB installation directory.
This issue isn't specific to the Intel Compiler, I also receive errors with the GCC Fortran compiler.
$ gfortran fengdemo.F
fengdemo.F:1:0:
#include "fintrf.h"
^
Fatal Error: fintrf.h: No such file or directory
compilation terminated.
You can use the Unix locate command to find files.
$ locate fintrf.h
/Applications/Matlab R2014a.app/extern/include/fintrf.h
In the directory where fengdemo.F is we can then pass the correct directory in using the -I option
-I../../include/
However, this produces linking errors as we haven't specified where the libraries for fintrf.h can be found. We can do this with the -L option (you will need to replace maci64 with the correct option for Linux - I can't remember it off the top of my head but you should be able to see it in the bin directory)
-L../../../bin/maci64/
Now we need to tell it what libraries to use with -leng -lmx and so the completed command is
$ ifort fengdemo.F -I../../include/ -L../../../bin/maci64/ -leng -lmx
and it should compile correctly.
We aren't finished yet though as it won't execute. We need to set up our PATH and DYLD_LIBRARY_PATH environment variables correctly. Specifically we need to add the bin and bin/maci64 directories of our MATLAB installation to PATH
$ export PATH=$PATH:/Applications/Matlab\ R2014a.app/bin/maci64:/Applications/Matlab\ R2014a.app/bin
and the bin/maci64/ and sys/os/maci64/ to DYLD_LIBRARY_PATH
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/Matlab\ R2014a.app/bin/maci64/:/Applications/Matlab\ R2014a.app/sys/os/maci64/
Note: On Linux DYLD_LIBRARY_PATH should be LD_LIBRARY_PATH. Thanks to Vladimir F for correcting me.
Now you can execute the program using
$ ./a.out
I have searched this but the questions I found are about getting the toolchain to work, my problem is that it works on all but a few directories. Also I am not building Linux.
I am trying to move a project from a Linux machine to Windows to make people happy. The same project builds fine under Linux (Ubuntu 12.04) using the Linux Binary for the same toolchain (I recently reloaded both toolchains from the same directory at Mentor to be sure, see details below).
I installed Cygwin, got the packages, set up paths, etc. In general the build works for 90% of the project BUT as make traverses the directory, it finds everything except two files (to clarify, these two are the first files in their respective directories, so I assume the problem will apply to the whole directory). The log below shows the first fail:
if I take lwip out of the build then it blows up on the next one
if I take the next one out of the build then everything else (quite a bit) compiles; then the linker fails on the two missing items as expected.
More precisely, e.g.
it finds /home/Nadi/project/version-2.9/external/freertos/Source/portable/GCC/ARM_CM3_MPU/port.c
but not /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c
from the directory that I am running make, "ls" finds the file that the compiler cannot.
log:
$ make
external/freertos
external/lwip
[cc] Debug/api_lib.o
arm-none-eabi-gcc.exe: error: /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c: No such file or directory
arm-none-eabi-gcc.exe: fatal error: no input files compilation terminated.
Makefile:189: recipe for target `Debug/api_lib.o' failed
make[2]: *** [Debug/api_lib.o] Error 1
Makefile:37: recipe for target `lwip_world' failed
make[1]: *** [lwip_world] Error 2
Makefile:160: recipe for target `extern' failed
make: *** [extern] Error 2
Details:
GCC Chain : arm-none-eabi-gcc ; gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-63)
Cygwin : CYGWIN_NT-6.1-WOW64
Although it might not help in this particular case, I faced similar problem with CodeSourcery's gcc not recognising Cygwin's paths like /cygdrive/d/foo.c at all - installation of cygpath package and setting environment variable export CYGPATH=c:/cygwin32/bin/cygpath (or set CYGPATH=c:/cygwin32/bin/cygpath in windows console) solved all the issues.
Be sure to define path to cygpath executable in exactly same way as above, regardless of Cygwin or Windows console used.
The details of my previous comment is that you're in for a lot of trouble using the windows/cygwin combo with Sourcery based cross-compilers. You can read more about this at SamyGo. Some of the issues using Windows, presented in all gory detail there, are:
Uses ACL to set file permissions and ownership (Not Linux compatible.)
Has it's own way of creating symbolic links (Not Linux compatible.)
Uses a non case-sensitive default for its fixed NTFS drives.
(Often and silently break archives originally compressed under Linux.)
Uses the Win32 (non POSIX) standard for file paths (Not Linux compatible.)
Uses the 2 characters Carriage-Return and New-Line ("\r" & "\n") for
End-of-Line (EOL) representation, contrary to POSIX, which uses only NL.
So in order not to waste time doing 3rd party debugging, you'd be much better off building your own cross-compiler from scratch, as shown in the XDA links in that other post. Since the advent of Android's, this is no longer difficult.
I am moving a project which uses clapack from osx to linux and experiencing some problems with it. I use clapack by downloading the cmake project, compiling and moving the necessary .h and .a files to a relevant location within my project.
I have used the same steps in both scenarios (osx and linux) and have the same exact source code on both machines however I cannot get the everything to link properly on linux.
the lined of code in my cmake file look like this
#-----------------------------------------------------------------------------
# INCLUDE CLAPACK
#-----------------------------------------------------------------------------
INCLUDE_DIRECTORIES(${VMT_PRJ_SOURCE_DIR}/CLAPACK)
LINK_DIRECTORIES(${VMT_PRJ_SOURCE_DIR}/CLAPACK/lib)
LINK_LIBRARIES(blas f2c lapack tmglib)
and the error I am getting looks like this
/CLAPACK/lib/liblapack.a(sgesvd.c.o): In function `sgesvd_':
sgesvd.c:(.text+0x456): undefined reference to `s_cat'
sgesvd.c:(.text+0x1fa4): undefined reference to `s_cat'
This is the first time I have done a port from osx to linux and don't know if there are some different requirements I need to make in order to link or what the problem is
Any help would be much appreciated.
Scott
The order of linking matters. Since liblapack.a needs functions from libf2c.a, the latter needs to come after the former. So changing
LINK_LIBRARIES(blas f2c lapack tmglib)
to
LINK_LIBRARIES(blas lapack f2c tmglib)
should help.
Good afternoon,
I am having difficulties with libxml2.
I tried to build the Perl module XML-LibXML which is part of our standard runtime environment. However, this time the installation on a RHEL5 box failed, because the build process complained about missing libxml2:
$> perl Makefile.PL LIB=/foo/lib/perl PREFIX=/foo INSTALLDIRS=site
enable native perl UTF8
running xml2-config...ok (2.7.6)
looking for -lxml2... no
looking for -llibxml2... no
libxml2 not found
However, the file was available. Starting the build with
perl Makefile.PL LIB=/usr/inform/target/lib/perl PREFIX=/usr/inform/target INSTALLDIRS=site
led to more evidence of the real problem:
[...]
Can't load 'blib/arch/auto/Conftest/Conftest.so' for module Conftest: /usr/inform/target/lib/libxml2.so.2: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
at test.pl line 2
[...]
After some investigations I found that the problem appears to be that libxml2.so is created with text relocation:
[tess91#INF-AW] lib$ eu-findtextrel libxml2.so.2.7.6
the file containing the function 'get_crc_table' is not compiled with -fpic/-fPIC
the file containing the function 'crc32' is not compiled with -fpic/-fPIC
the file containing the function 'gzerror' is not compiled with -fpic/-fPIC
[...]
Ans since we have SElinux active on the target machine, linking against libxml.2 failed!
Is there any possibility to create libxml2 properly, or do I have to ask the admin to twist SElinux to allow relocations?
I really can't believe I am the olny one having this problem on Linux with SElinux active. What am I missing?
Any help apprecitated!
Regards,
Stefan
The simplest way is to have your administrator yum install libxml2-devel or even yum install perl-XML-LibXML. Otherwise, see if you can add -fPIC to the CFLAGS in the Makefile.PL.
I assume you are on 32-bit x86, any other architecture wouldn't work without -fPIC.
I just found a possible explanation:
During the build of libxml2 the compiler flag -fPIC is indeed used, so the code is created position independant, BUT:
When creating the shared library, the static libz is linked against it. Is that the source of my problem? That including a static lib in a shared executable taints the library by introducing non-relocatable code?
The fact that the symbols eu-findtextrel should already have pointed me in that direction, since crc32, get_crc_table, etc. look like encryption centered code...