We're using a modified compiler from under xcode. Mostly this works. However, as part of the modification, the generated .o files are not ones that the standard apple tools recognise, and in particular libtool does not like them. The effect of this is that we can't seemingly support static libraries (ie. .a files).
Does anybody know how to override the libtool we use? Worse case then is that I could write a script that did the right thing. As it is, I can only see how to replace the compiler.
FTR The only way I've managed to do so for now is to override the libtool under:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
copying the original to libtool.real and having a shell script that looks at the .o files past and works out what to do. The one extra issue I've noticed (affecting how you write the shell script) is that the "ranlib" operation recursively calls the same script, so you need to be careful and only do the modified operation when the parameters precicely match the basic case (I check for there being more than one .o file either directly or via a filelist).
Related
I want to make a library that depends on other libraries.
I have been able to make the static .a files of the dependencies and have them along with the header files readily available in a directory. Running them through file confirms that I have successfully compiled these for all architectures.
When I try to make the final library, it tells me
ld: warning: ignoring file /usr/local....dylib, building for architecture-A but attempting to link with file built for architecture-B
It is correct that the library under the mentioned path is only compiled for the host architecture A (installed via package manager). However, in the LDFLAGS I have -L${libdir}/libs (the folder where the libs are) but make only seems to care about the ones in my usr/local/..folder.
Are there other ways to specifically point make to check the {libdir}/libs folder or even make make ignore the paths from pkg-config in case it searches there first, finds the unfit files and never gets to try the ones I passed in my LDFLAGS?
You write ...
I have been able to make the static .a files of the dependencies and have them along with the header files readily available in a directory.
... but this is probably irrelevant because you seem to be trying to build a shared (i.e. dynamic) library. Static libraries and shared ones don't mix very well.
Are there other ways to specifically point make to check the {libdir}/libs folder or even make make ignore the paths from pkg-config in case it searches there first, finds the unfit files and never gets to try the ones I passed in my LDFLAGS?
You are focusing on make, but make doesn't have much to do with it. It is the linker, not make, that performs the search and the actual link. make just executes the link command you told it to execute.
But yes, you can control the linker's library search order by controlling the order of its command-line options. Library directories specified via -L options are searched in the order they appear on the command line, and all of them before the linker's default library directories.* If ensuring a proper order of arguments does not get you the link you want then it is very likely because the linker is ignoring your static libraries because it is trying to build a dynamic one.
However you should be able to bypass the search altogether by specifying a full path and filename of the library you want to link instead of using -L or -l options. For example, instead of -L/path/to -lfoo, you might use /path/to/libfoo.dylib (or /path/to/libfoo.a). You don't normally want to hardcode paths like that, but in this case it might serve a diagnostic purpose to do so.
Note also that it is rarely a good idea to link against dynamic libraries that are not installed in their intended location, especially if the libraries are not part of the same project. It may seem at first to work ok, but it contributes to problems with finding the libraries at runtime (and dynamic libraries do need to be found at runtime, too). The same does not apply to static libraries, but that comes with its own set of advantages and disadvantages.
* There's more to it than that, but this answer is already long. Read the linker docs if you want more detail.
need some help with using a 3rd party makefile when building my own project.
There isn't a way to what you want directly. CMake doesn't provide a facility to include files into its generated files. (ie: include a "3rdparty.mk" into a CMake generated Makefile.) Nor can you directly include a "generated-file-type" (ie: a Makefile) into a CMakeLists.txt. CMake's ExternalProject won't let you do that either.
What you need to do is somehow "parse" the makefile that has the information that you desire. There are a myriad of ways that you can do this. For example, you could write a shell-script wrapper that would grep your makefile for what you need then construct a CMake command line with the variables you want defined, and output it or call cmake for you. Depending on how comfortable you are with shell (or perl, python, etc.) you might feel this is the best option.
If you know these values will never (or very rarely change), you can hard code them in to your CMakeLists.txt (not recommended) or into a file you can include() (better).
You could also stay in CMake-land and use CMake's ExternalProject to help you. Using ExternalProject, you can:
Fetch your 3rd party libraries (download, copy, unzip, etc)
Patch the Makefiles of these libraries
Run make on those patched makefiles
Now, this patch that I mentioned is something that you'd have to write yourself, and keep with the source of your primary project. The content of this patch would be a new target for make that would write a file that you could include in your CMakeLists.txt via include(). You could start simply, and have this new make target (eg: make output_variables) write a list of set() commands to lib_A.cmake. After comfortable with that, you could move on to more complicated output; like writing a lib_A-config.cmake file that CMake's find_package() would understand.
Granted, the last option is probably the most complicated but it might make maintenance of your primary project easier, reducing pain in the future. You'll also gain a deeper understanding of CMake.
i'm new year and I need some answer. I searched on the web to some answer but i didn't found anything usefull. What am i searching is for a shell programms that when you execute it, create a Makefile with the binary name in arguments like :
./automakefile.sh hello .
Will build you a Makefile with a binary name called hello.
I hope you guys will help me, i'm counting on you <3
There is, unfortunately, no such magic command. If there was, we wouldn't need Makefiles to start with because the magic would most likely have been incorporated in the compiler.
There are several reasons why there isn't a command like that.
Given a random binary file, you can't generally say what programming language it was written in.
You also can't tell what source file were used to compile the binary file from, or where in the file hierarchy they are located (not just where they were located when the binary file was compiled last time, maybe on another system).
You don't know the dependencies between the source code files. Makefiles are primarily useful for keeping track of these (and compiler flags etc.), so that changing one single source file in a big project does not trigger a recompilation of everything.
You don't know what compiler to use, or what flags to pass to it. This is another thing a Makefile contains.
There are build tools available for making the creation of Makefiles easier, and for making them portable between systems on different architectures (the Makefiles that is, not necessarily the programs, that's down to the programmer). One such set of tool is GNU's autotools, another is CMake, and I'm sure there are others as well, but those are the ones I use.
Now you're facing another but similar problem, and that is that you still need to learn the syntax of, and writ,e your Makefile.am and configure.ac files (for the GNU tools), or your CMakeLists.txt files (for CMake).
I am trying to compile a bash project into a distributable binary. I tried shc, and it worked, except all my source statements were broken. I have numerous source statements to keep the code base cleaner, but they are broken when compiled with shc. How can I compile down my bash project so that instead of having a bunch of .sh files, the end user can just have one single file?
Shc is an obfuscator, not a compiler. At the end of the day, it still invokes /bin/sh or whatever, and feeds it your original script. It has not a slightest idea what your script actually does. If it needs an additional file to source, you have to supply it at an appropriate location.
You may want to investigate things like SHAR. Build anarchive, then compile it with shc if you want.
It sounds like all you're missing is a facility to expand all your source statements. That should be fairly easy to write if your codebase is fairly consistent in its use of those statements: just write a script to expand them inline and away you go.
Alternatively, just put all your scripts into a single Zip file or tarball and tell the user to extract the contents of that one file, or if even that is too much I'm sure you can imagine a way to encode the zipped contents of all the non-main files into a giant comment at the bottom of the main file, and have it extract what it needs before proceeding.
Or, you know, use the appropriate installer for your system. Build an RPM for RHEL or a Debian package or a Windows MSI or whatever....
I'm looking for the best practice for including GNU Bash in the cross-compilation of NetBSD using the build.sh script. Right now, my plan is to include it in usr/src/gnu/dist and then create the relevant Makefiles in usr/src/gnu/usr.bin but I was wondering if there was an easier/better way to do this?
The new way is to place files under src/external//. For bash, it's src/external/gpl3/bash. (This directory is called ${EXTTOPDIR.bash} hereafter.)
The original source is expanded into ${EXTTOPDIR}/dist as is. Other files and directories are made at ${EXTTOPDIR}. Start with copying src/external/gpl2/xcvs for example. (BSD) makefiles that are placed (out of the original source) are called "reach-over"; meaning that build procedures are kept without disturbing the original source. This helps to ease maintaining of the original source. (And no, all of these are not documented at all, unfortunately.)
If you need to hook the build as "tools", you'll need something more to care. The procedure is also not documented. Just learn from the source.
If you work on the official NetBSD tree, you have something more to learn about CVS; use vendor branch, etc.
HTH,
Masao