Simple question, what's the .A in libobjc.A.dylib? Sorry for the simple question, but it isn't exactly easy to Google information about the letter "A" without Google thinking you're using it as the singular "a" as in "a cat."
It is part of the name used to indicate a version of the library and allows multiple versions of the same library to be present. There is often an unadorned name which links to the current version, as is the case with libobjc:
$ ls -l libobjc.*
-rwxr-xr-x 1 root wheel 12937200 9 Jul 2016 libobjc.A.dylib
lrwxr-xr-x 1 root wheel 15 7 Nov 2015 libobjc.dylib -> libobjc.A.dylib
This shows that libobjc.dylib is a symbolic link to libobjc.A.dylib.
As a different example consider libgcc:
lrwxr-xr-x 1 root wheel 17 7 Nov 2015 libgcc_s.1.dylib -> libSystem.B.dylib
lrwxr-xr-x 1 root wheel 19 20 Dec 2016 libgcc_s.10.4.dylib -> libgcc_s.10.5.dylib
-rwxr-xr-x 1 root wheel 29480 2 Aug 2015 libgcc_s.10.5.dylib
Here there are three names, and two distinct versions, of the library available.
Software which requires a particular library version can link with the versioned name. Links are used when a later version is completely compatible with an earlier version, so software linking with the earlier version actually gets the later one.
All of this is only an issue with dynamic linking. With static linking the actual version of the library used during compilation is combined into the software binary and so there is no dependency on the library version(s) currently installed on the system.
I believe this is simply a naming convention to distinguish a dynamic library from it's symbolic link and the fact that any .A.dylib located within /usr/lib has the dependency of libsystem.B.dylib.
Using ls with grep shows all the .A.dylib files in /usr/lib:
$ ls -lat | grep A.dylib
-rwxr-xr-x 1 root wheel 6076144 Jul 14 23:41 libicucore.A.dylib
-rwxr-xr-x 1 root wheel 14249664 Jul 14 23:41 libobjc.A.dylib
-rwxr-xr-x 1 root wheel 85136 Jul 14 21:29 libBSDPClient.A.dylib
-rwxr-xr-x 1 root wheel 32416 Jul 14 21:28 libDHCPServer.A.dylib
-r-xr-xr-x 1 root wheel 116352 Jul 14 21:27 libalias.A.dylib
-rwxr-xr-x 1 root wheel 497312 Jul 14 21:27 libpcap.A.dylib
-rwxr-xr-x 1 root wheel 530800 Mar 22 16:56 libtidy.A.dylib
-r-xr-xr-x 1 root wheel 84704 Mar 22 16:55 libipsec.A.dylib
lrwxr-xr-x 1 root wheel 21 Oct 1 2016 libBSDPClient.dylib -> libBSDPClient.A.dylib
lrwxr-xr-x 1 root wheel 21 Oct 1 2016 libDHCPServer.dylib -> libDHCPServer.A.dylib
lrwxr-xr-x 1 root wheel 16 Oct 1 2016 libalias.dylib -> libalias.A.dylib
lrwxr-xr-x 1 root wheel 18 Oct 1 2016 libicucore.dylib -> libicucore.A.dylib
lrwxr-xr-x 1 root wheel 16 Oct 1 2016 libipsec.dylib -> libipsec.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libmx.A.dylib -> libSystem.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libobjc.dylib -> libobjc.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libpcap.dylib -> libpcap.A.dylib
lrwxr-xr-x 1 root wheel 15 Oct 1 2016 libtidy.dylib -> libtidy.A.dylib
Now for .B.dylib:
$ ls -lat | grep B.dylib
-rwxr-xr-x 1 root wheel 60848 Jul 14 21:28 libSystem.B.dylib
lrwxr-xr-x 1 root wheel 17 Oct 1 2016 libSystem.dylib -> libSystem.B.dylib
lrwxr-xr-x 1 root wheel 17 Oct 1 2016 libgcc_s.1.dylib -> libSystem.B.dylib
Take any of the .A.dylib and check it's dependencies:
$ otool -L libobjc.A.dylib
libobjc.A.dylib:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 307.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
$ otool -L libipsec.A.dylib
libipsec.A.dylib:
/usr/lib/libipsec.A.dylib (compatibility version 1.0.0, current version 300.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
$ otool -L libicucore.A.dylib
libicucore.A.dylib:
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 57.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
...
Is it a dynamic library or a static library? file tells us that's it's a dynamic library all the way:
$ file libobjc.A.dylib
libobjc.A.dylib: Mach-O universal binary with 3 architectures: [x86_64: Mach-O 64-bit dynamically linked shared library x86_64] [i386] [x86_64h]
libobjc.A.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libobjc.A.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libobjc.A.dylib (for architecture x86_64h): Mach-O 64-bit dynamically linked shared library x86_64h
It seems as though the logic here points to a means of identifying the dynamic libraries ( A ) which all have the common trait of depending on library ( B ).
The .A files are static libraries. You can find more information on them on the Wikipedia.
They are collections of object files that are linked into the program during the linking phase of compilation, and are not relevant during runtime
Related
I have a java project that builds correctly using mvn
># mvn package
[ok]
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/app.jar
change sources, build it again and the mtimes change
># mvn package
[ok]
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app.jar
as expected. Also if I diff one of these jar files with a copy of an older one, it is different.
I import this project into IntelliJ IDEA and build
Build completed successfully with 3 warnings
however
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app.jar
the mtime has NOT changed, and diff reports that the files are identical to copies of the earlier versions.
Why is IDEA not producing new jar files?
Your question is very similar to this one, which I have already answered: intellj IDEA doesnt build jar properly
It helps understanding.
Well looked at the catches. (click zoom)
This uses nvmw local to the project, nothing prevents you from using your nvm version.
Namely intellij provided well, its own build construction system, to create jars without maven. (Even though I personally have not been able to set it up correctly for it to work for starting the application.)
But if you are looking to create a war, I can give you more information to create a war file ...
I use spring boot but the principle remains the same with all simple java projects
When I try to run a simple perl6 script on MSYS2-64 (bash.exe) on Windows 7 it says:
Could not open my-perl6-script.pl. Failed to stat file: no such file or directory
The same script runs perfectly fine on CMD.exe so I guess it's some incompatibility between perl6 and MSYS2.
$ perl6 -v returns:
This is Rakudo Star version 2018.04.1 built on MoarVM version 2018.04.1 implementing Perl 6.c.
The bin folder of perl6 is:
-rwxr-xr-x 1 win7 None 537938 May 11 2015 libgcc_s_sjlj-1.dll
-rw-r--r-- 1 win7 None 130262 May 7 2018 libmoar.dll.a
-rwxr-xr-x 1 win7 None 57681 May 11 2015 libwinpthread-1.dll
-rwxr-xr-x 1 win7 None 6633702 May 7 2018 moar.dll
-rwxr-xr-x 1 win7 None 57225 May 7 2018 moar.exe
-rw-r--r-- 1 win7 None 104 May 7 2018 nqp.bat
-rw-r--r-- 1 win7 None 104 May 7 2018 nqp-m.bat
lrwxrwxrwx 1 win7 None 23 Jun 19 2018 perl6 -> /c/rakudo/bin/perl6.exe
-rw-r--r-- 1 win7 None 242 May 7 2018 perl6.bat
lrwxrwxrwx 1 win7 None 23 Jun 19 2018 perl6.exe -> /c/rakudo/bin/perl6.bat
-rw-r--r-- 1 win7 None 248 May 7 2018 perl6-debug-m.bat
-rw-r--r-- 1 win7 None 242 May 7 2018 perl6-m.bat
It doesn't matter if I run the script using perl6, perl6.exe or perl6.bat; they all give the same error. I'd like to run perl6 scripts on MSYS2-64. What should I do? Thanks
I installed Rakudo for Windows and made a custom perl6 shell script:
#!/bin/sh
/c/rakudo/bin/moar --execname="$0" --libpath='C:\rakudo\share\nqp\lib' --libpath='C:\rakudo\share\nqp\lib' --libpath='C:\rakudo\share/perl6/lib' --libpath='C:\rakudo\share/perl6/runtime' 'C:\rakudo\share\perl6\runtime\perl6.moarvm' "$#"
I copied perl6.bat to perl6, changed the initial path to moar to an MSYS-style path, and changed from cmd to sh quoting and arugment conventions.
Example run, from cmd:
C:\Users\cxw>perl6 -v
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
From the shell opened by msys2_shell.cmd:
$ uname -a
MSYS_NT-6.1-7601 Desktop 3.0.7-338.x86_64 2019-07-03 08:42 UTC x86_64 Msys
$ export PATH="$PATH":~/bin
$ cat foo.p6
use v6;
(2+2).say;
$ perl6 foo.p6
4
For what it's worth, my Rakudo bin dir:
$ ls -l /c/rakudo/bin
total 8033
-rwxr-xr-x 1 cxw None 930663 May 11 2017 libgcc_s_seh-1.dll
-rw-r--r-- 1 cxw None 136146 Mar 30 21:55 libmoar.dll.a
-rwxr-xr-x 1 cxw None 56978 May 11 2017 libwinpthread-1.dll
-rwxr-xr-x 1 cxw None 7021172 Mar 30 21:55 moar.dll
-rwxr-xr-x 1 cxw None 64066 Mar 30 21:55 moar.exe
-rw-r--r-- 1 cxw None 126 Mar 30 21:56 nqp.bat
-rw-r--r-- 1 cxw None 126 Mar 30 21:56 nqp-m.bat
-rw-r--r-- 1 cxw None 242 Mar 30 21:56 perl6.bat
-rw-r--r-- 1 cxw None 248 Mar 30 21:56 perl6-debug-m.bat
-rw-r--r-- 1 cxw None 242 Mar 30 21:56 perl6-m.bat
Currently I am creating a simple project which will install a utility shared library.
Here's my CMakeLists:
cmake_minimum_required (VERSION 2.6)
project(MathLibs CXX)
add_library (${PROJECT_NAME} SHARED
fact.cpp
fibo.cpp
isPrime.cpp
)
install (TARGETS ${PROJECT_NAME}
RUNTIME DESTINATION ${PROJECT_NAME}/bin
LIBRARY DESTINATION ${PROJECT_NAME}/lib
ARCHIVE DESTINATION ${PROJECT_NAME}/lib)
Since I do not have root privileges I cannot install the shared library in system lib folder. I override the CMAKE_INSTALL_PREFIX to $HOME/apps.
When I build the shared library it had the executable permissions.
Here's the build folder with the shared library:
-rw-rw-r-- 1 ameya ameya 9714 Jun 18 20:02 CMakeCache.txt
drwxrwxr-x 5 ameya ameya 4096 Jun 18 20:02 CMakeFiles
-rw-rw-r-- 1 ameya ameya 2701 Jun 18 20:02 cmake_install.cmake
-rw-rw-r-- 1 ameya ameya 84 Jun 18 20:02 install_manifest.txt
-rwxrwxr-x 1 ameya ameya 6808 Jun 18 20:02 libMathLibs.so
-rw-rw-r-- 1 ameya ameya 7748 Jun 18 20:02 Makefile
drwxrwxr-x 3 ameya ameya 4096 Jun 18 20:02 test
After installing the executable permissions disappears.
Here's the install folder location:
-rw-r--r-- 1 ameya ameya 6808 Jun 18 20:02 libMathLibs.so
What am I missing in the CMakeLists.txt to correct this?
They said that CMake doesn't set execute permissions on installed library because on Linux libraries don't need to be executable.
As for library's permissions in build tree, these are set not by CMake but by the linker.
If you want executable permissions of installed library for some reason, use PERMISSIONS option in install() command.
After looking for more details online I found this referenced in the CMake bugs report.
The handling of shared library on different systems is different I tried using Ubuntu and a Fedora workstation.
On Ubuntu system the system installed shared libraries do not have the executable bit set, but on the Fedora Workstation the same library had the executable bit set.
One can have look at the ${CMAKE_ROOT}/cmake/Modules/Platform/Linux.cmake,
which has the CMAKE_INSTALL_SO_NO_EXE macro defined(sorry for the typo in my earlier reply).
Flag "-fprofile-instr-use" generates error given below.
This issue occurs even if we build llvm,clang and compiler-rt using cmake or configure.
Please let me know your inputs to resolve this issue
error: Could not read profile: Invalid file format (bad magic)
Thanks,
Steps to reproduce this issue:
$ clang -O2 -fprofile-instr-generate hello.c -o c1.out
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
$ ./c1.out
Hello world
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
-rw-r--r-- 1 root root 104 Jul 11 10:10 default.profraw
$ clang -O2 -fprofile-instr-use=default.profraw hello.c -o c2.out
error: Could not read profile: Invalid file format (bad magic)
1 error generated.
Clang version (July 10th-2014 build from stage):
$ clang -v
clang version 3.5.0 (llvm.org/git/clang.git 5f9d646cba20f309bb69c6c358996d71912c54cd) (llvm.org/git/llvm.git dc90a3ab8ffc841a442888940635306de6131d2f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;#m64
Candidate multilib: 32;#m32
Selected multilib: .;#m64
OS: Ubuntu 14.04
LLVM configure: ../llvm/configure --enable-profiling --enable-optimized --enable-shared --disable-debug-runtime --enable-targets=x86
It turns out that step 3 outlined here: http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
is required even if you only have 1 output file you are using. "Combine profiles from multiple runs and convert the “raw” profile format to the input expected by clang" makes it sound like you should only do this if you have multiple profiles, but you need to do it unconditionally.
So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.