I know there exist crti.o crt1.o crtn.o in /usr/lib on Solaris 10.
But these files are absent on Solaris 7.
These files should be included with the compiler, under the same installation directory. If you are using the Sun compiler check under /opt/SUNWspro/lib/; for gcc look under /usr/local/lib/gcc-lib/. The exact directory depends on the version of the compiler, the platform architecture, and your installation options. Normally the compiler will link this object into your program automatically, if you are producing an executable file as output.
The reason is likely due to Solaris 7 not bundling a C compiler unlike Solaris 10. These files are C runtime objects only required when you need to link new executables.
Related
Because my understanding of this problem is limited, please excuse me if I provide irrelevant details.
Question
I have two versions of MingGW on my computer, and both are 32-bit. The first one is what I call "basic MinGW", and it's the one I installed using mingw-get several years ago. The other one came with MSYS2.
Here are the constraints I am dealing with, details provided in the postscript:
My program depends on library A, which I can only compile from source using the MSYS2 MinGW.
My program depends on B.dll, a file that was provided to me. I do not have the source.
Using objdump, I discovered that B.dll has file format pe-i386
Using objdump, I discovered that programs compiled with the basic MinGW have file format pe-i386
Using objdump, I discovered that programs compiled with the MSYS2 MinGW have file format pe-x86-64
The end result is this:
My program cannot compile with the basic MinGW because library A (which must be compiled with MSYS2 MinGW) is incompatible
My program cannot compile with the MSYS2 MinGW because B.dll is incompatible
What is the difference between these two file formats? If they are both 32-bit, why can't I compile them together? Is it possible to convert B.dll to be compatible with the MSYS2 MinGW?
Details
Library A is libevent. At some point, libevent requires netioapi.h which does not appear to be present in the basic MinGW. However, MSYS2 MinGW is able to compile libevent.
B.dll is provided to me in Modelsim. It is the library you must link against fro compiling Verilog PLI programs.
I have download that code from github.
Whenever that code tries to check mexopencv (a file inside lib folder). It shows an error on Matlab 2017a that is:
[error 3] please make sure gcc >= 4.4 g++ >= 4.4 is installed ...
I am having a gcc version of 8.8.0
Following is the description of system
Window 10
Visual Studio 2012
Matlab 2017a
opencv 2.4.10
mexopencv (install from your folder LIB)
You might lack of standard libraries (.dll in Windows but .lib in Linux). The code was developed under Linux (help is also only provided for Linux systems) and once tested under Windows 7.
The method was tested under OS linux lubuntu 14.04, CPU intel i5 and
16GB of RAM. This guide was written under a linux-based distribution
scope, more precisely debian. Unfortunately we lack experience to
address bugs or any problem that could emerge in non-linux OS, we will
provide only linux OS help regarding execution problems, we apologise.
we tested this code on Windows7. We successfully installed opencv
2.4.10 following this tutorial: [http://www.learnopencv.com/install-opencv3-on-windows/]
This suggests that the mex-function is also linux-based. The error should vanish if you compile the source code yourself on your system, e.g. with MinGW (also GCC), see here.
EDITED:
the README.markdown file (under LIB/mexopencv-master.zip) provides a little guide through the installation process of both, openCV and the mexopencv function for unix (including ubuntu 14.04) and Windows systems. The latter states:
Browse to mexopencv root folder, and type the following in the MATLAB
command window:
>> mexopencv.make
By default, mexopencv assumes the OpenCV library is installed in
C:\opencv. If this is not the case, specify the path as an argument:
>> mexopencv.make('opencv_path', 'c:\your\path\to\opencv')
Note that if you build OpenCV from source, this path specification
might not work out of the box. You need to replace dll files in the
OpenCV package with newly built binaries. Or, you need to modify
+mexopencv/make.m to correctly link your MEX-files with the library.
To remove existing mexopencv binaries, use the following command.
>> mexopencv.make('clean', true)
It requires a standard C++ compiler supported by Matlab (see here), any Visual Studio installation should be OK, as an open-source option MinGW is recommended. Just remember to pick the right system (usually 64-bit).
I have compiled Mex file successfully on my laptop. But when I am running it, it says Invalid mex file 'c:\newfolder\filename.mexw32' The specified module could not be found.
System specification:
OS: windows 7
MATLAB 2010a
Microsoft Visual Studio 2008.
The same mex file is compiled and run successfully on my PC under XP SP3.
This MathWorks support link suggests two possible reasons to your problem:
You do not have all of the necessary libraries that the MEX-function is dependent upon.
You are running a MEX-file on a different version of MATLAB than it was compiled on.
Either way, to locate the source of this error it says that you need to list all dependent library files and verify their existence in the system you're trying to run the MEX file on, and also recommends the Dependecy Walker as the tool to to do that.
Do you you the mex file on another system than the one it is created on?
If so, then you need to install the Microsoft Visual C++ Redistributable on that machine.
I had this problem also when upgrading from Matlab2010a/VS2008 to Matlab2013a/VS2010.
All my environment variables were sent correctly.
A reboot fixed problems with OpenCV dlls not being found, I assume that it was still trying to link to the OpenCV dlls for VS2008 (even though I had changed the path). However still my mex file could not find libmex.dll.
When I installed Matlab2013a, I did not uninstall the old version (in case I wanted to go back).
However that was the cause of my problem.
Once I uninstalled the old version of Matlab and rebooted again, the problem was gone.
I had a similar problem. I was only linking against 1 'lib' so I simply copied that lib into the same folder as the mexw64 and it worked.
I have not poked around for the correct place to tell MATLAB to add the lib's real location to whatever path it's looking at.
May I know if I can cross compile the Solaris x86 library from Solaris sparc server?
The source code is mainly in C++ (some C). I need to use the Solaris C++ compiler CC to compile. I understand that some compile or link flags are different between sparc and x86. I have done a check to make sure that the flags I used are common.
Is it possible to simply copy the library compiled in sparc to x86? Or I need to apply specific flag during compiling and linking?
Thanks,
The Sun/Oracle Studio C++ compilers do not support cross-compilation. You would need to use another compiler that does, like a specially built gcc.
Simply copying the library can't work - SPARC and x86 are very different instruction sets, with no binary compatibility between the two.
Even if you could cross compile the Solaris libraries on SPARC for x86, it would seem a lot simpler to just install the x86 compilers and libraries. The interdependencies of these libraries is probably so complex that such a project would probably not work.
What's preventing you from just downloading and installing the Studio software on x86 Solaris?
Oracle Sun Studio C++ compiler (CC) has --xarch option with big variety of architectures. There are: sparc, amd64, pentium_pro and various extensions/modifications. This flag should be provided for both compiler and linker if you compile and link in separate steps.
You can verify target architecture with file command; e.g:
bash-3.2$ file /usr/bin/CC
/usr/bin/CC: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
Please, refer to CC manual for details:
Sun Studio 11 C++ Man Page
I compile the perl DBI package on solaris 10 say SERVER1 with say perl 5.8.10 installed on it and create DBI.
Now I copy the above DBI.so and the DBI.pm files to another solaris SERVER2 machine with the same hardware and the same version of perl.
Can I be sure that the DBI package will run smoothly and I will not get any run-time errors in future ?
Please note that I dont have the flexibilty to install a C compiler SERVER2.
Hardware does not matter so much as you think, the operating system abstracts this away nicely. For binary compatibility, the minor version must match, so the other Perl must also be from the 5.8 series. (By the way, 5.8.9 was the last one, 5.8.10 does not exist.)
As you're talking about a dynamic library, the integration on the C level is much more important. Are the libraries referenced from the DBI.so compatible (e.g. libc.so has the same version on both machines)? Check with the ldd command.
In case of mismatches, you will not get run-time errors, but very obvious crashes at compile time when perl attempt to load DBI.
The answer is the same as in this question: How can I install Perl modules on a restricted server? -- install your modules and libraries on a system with the same architecture (using a special installation directory), then copy the modules over to your restricted system.
You'll need a C compiler somewhere (unless you can find pre-compiled binaries of the .so or .dll files you need), but it doesn't have to be on the intended target.