I'm using Debian8.7 which is installed gcc4.9.2 via apt-get.
I built glibc2.24 and gcc6.3 with --prefix=/home/me/local, that looks finished correctly, but when using these adding LD_LIBRARY_PATH=/home/me/local/lib I got an error 'segmentation fault'.
I don't have any idea to solve this problem, could you help me?
You won't be able to use custom glibc just by setting the LD_LIBRARY_PATH (e.g. your app will still use dynamic linker from old Glibc). See this question for details on how to achieve what you want. Glibc testing wiki may also be of help.
Related
I am getting into a position where I have to use other people code for projects, for example openTLD. I want to change some of the code to give it more functionality and use it in a diffrent way. What I have found is that many people have packaged their files in such a way that you are supposed to use
cmake
and then
make
and sometimes after that
make install
I don't want to install the software on my system. What I am looking to do is get these peoples code to a point where I can add to it in Eclipse or even just using Nano and then compile it.
At what point is the code in a workable/usable state. Can I use it after doing cmake or do I need to also call make? Is my thinking correct that it would be better to edit the code after calling cmake as opposed to before? I am not going to want my finished code to be cross platform supported, it will only be on Linux. Is it easer to learn cmake and edit the code befor running cmake as opposed to not learning cmake and using the code afterwards, if that is possible?
You question is a little open ended.
Looking at the opentld project, there is a binary and a library available for use. If you are interested in using the binary in your code, you need to download the executables(Linux executables are not posted). If you are planning to use the library, you have two options. Either you use the pre-built library or build it during your build process. You would include the header files in your custom application and link with the library.
If you add more details, probably others can pitch in with new answers or refine the older ones.
I am currently using Google Breakpad in my Linux app. I built breakpad by configure&make, I am linking /src/client/linux/libbreakpad_client.a and it works fine, dump is created in case of crash.
Now I would like to also use common/linux/http_upload functions to upload dump somewhere similar way as it is done in src/tools/linux/symupload/minidump_upload but I get undefined reference to google_breakpad::HTTPUpload::SendRequest...
How to proceed? Is is not built on Linux into some library? Linking libbreakpad_client.a and libbreakpad.a does not seem to be enough. Do I need to build it somehow separately? Thanks for help.
It requires src/common/linux/http_upload.cc to be included in (for example) libbreakpad_client.a, I added that line to Makefile.am to src_client_linux_libbreakpad_client_a_SOURCES section. It seems it is not built otherwise by any configure arguments or I missed it.
I'm currently running a heavily modified Synology DSM (x86 bromolow based) on my server (bootstrapped, etc.), and for some services, I would need node.js.
And thus, I've been following the tutorials, more or less. Installed the required packages (python2.7, make, gcc, etcetera), grabbed the source, checked out the latest stable, and tried to compile.
But I ran into a slight issue while trying to run configure. Here's the output log: http://pastebin.com/BPXX4XiY
Then tried with Python2.6 too: http://pastebin.com/Xg4qHspG
Problem is, Error 38 and "Function not implemented" does not give a slightest hint on what might be missing - there is simply no reference to it.
Did anyone else have this problem, and if yes, how did you solve it?
EDIT
Using the solution from here, it still does not work. /dev/shm/ (after manually creating the node, and mounting it) is there, with 0777 access rights, and yet Python still returns the same error.
I'm a good Java programmer, albeit the first languages I learnt were C/C++. Anyway, for work reasons, I switched to Java and web languages. Sometimes I get interested in this or that Linux project, usually coming as a git or svn repository... The problem is that I usually clone the repo, I try to configure it, I install all the needed libraries (and this takes ages), maybe finally I succeed... but then make fails or configure itself fails, complaining about some tool that is missing. Or maybe I installed two versions of the same library and the configure script gets the wrong one, or boring problems like this.
Anyway, I see loads of people using those tools everyday, so it must not be so difficult after all!
Can you point out resources that may help in the first steps?
Thanks
What you are referring to are known as autotools and make
autotools are used to generate scripts and build files that can be used to build as well as install a program/package/software (whatever you call it)
Here is wikipedia link for the GNU build system in general.
And refer to this link for details about the autotools and related stuff
It may take longer, but if you are interested in how to fix those problems yourself I recommend learning how autoconf and automake work. I made a positive experience with the book "Autotools: a practitioner's guide to Autoconf, Automake and Libtool". I read the dead-tree version but it is also available online: http://fsmsh.com/2753.
I have an executable I want to be able to distribute and run in other Linux systems. Is there a way to be reasonably sure if this will work, without access to the final runtime environment?
For example, I am concerned my executable could be using a dynamic library that is only present on my development machine.
Supply any relevant shared libraries with the executable, and set $LD_LIBRARY_PATH in a shell script that invokes the executable to tell the linker where to find the shared libraries. See the ld.so(8) man page for more details, and be sure to follow the appropriate licenses.
Take a look at the Debian (.deb) and Redhat (.rpm) packaging stuff. This is the installer for your package. They aren't all that difficult, and you can tell it to reference other packages that have the required shared objects.
The packaging tools can usually repair packages that are missing libraries and so on. It will also help you place your binaries in such a way that you don't need to set LD_LIBRARY_PATH or put a shell-script front end on your executable.
They aren't that difficult to learn either. Spend a day playing with each and you'll get a passable installer package.
Is there a way to be reasonably sure if this will work, without access to the final runtime environment?
One's environment could be a different architecture than yours, even while it stays Linux. Therefore, the only sure way to get your program to the widemost audience is to ship source code.
Couldn't you just statically linking everything into a supper massive black hole^W^W binary do the trick?