I'm currently trying to port a SIP stack library (pjSIP) to the PSP Console (using the PSPSDK toolchain), but I'm having too much trouble with the makefiles (making the proper changes and solving linking issues).
Does anyone know a good text, book or something to get some insight on porting libraries?
The only documentation this project offers on porting seems too dedicated to major OS's.
Look at other libraries that were ported over to the PSP. Doing diffs between a linux version of a library, and a PSP version should show you.
Also, try to get to know how POSIX compatible the PSP is, that will tell you how big the job of porting the library over is.
The PSP is not UNIX and is not POSIX compliant, however the open source toolchain is composed by gcc 4.3, bintutils 1.16.1 and newlib 1.16.
Most of the C library is already present and can compile most of your code. Lots of libraries have been ported just by invoking the configure script with the following arguments:
LDFLAGS="-L$(psp-config --pspsdk-path)/lib -lc -lpspuser" ./configure --host psp --prefix=$(pwd)/../target/psp
However you might need to patch your configure and configure.ac scripts to know the host mips allegrex (the PSP cpu), to do that you search for a mips*--) line and clone it to the allegrex like:
mips*-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
mipsallegrex*-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
Then you run the make command and hope that newlib has all you need, if it doesn't then you just need to create alternatives to the functions you are missing.
Porting is very platform specific, so I don't think you will find much general literature on the subject.
Off the top of my mind, some things you may encounter:
endianness
word size
available libraries
compiler differences
linker differences (you've already seen that one)
peripheral hardware differences
...
I did some more research and found this post at ps2dev forum:
The PSP is not a Unix system, and the pspsdk is not POSIX compliant. It's close in some places, but you can't expect to just take any code that compiles fine on a POSIX system and have it work. For example:
pspsdk uses newlib, which lacks some of glibc's features and headers.
libc is not linked by default, so typical autoconf tests will fail to build
autoconf knows nothing about the PSP
defining PSP_MODULE_INFO and running psp-fixup-imports on the executable are required, otherwise it won't run
You should look at all of the other libraries and programs that have been ported (in the psp and pspware repositories). All SDL libs use autoconf, for example.
I think this delivers more detail into what I was looking for, and also show the #[Jonathan Arkell] point of looking into libraries that already been ported.
Thanks for your replies.
Related
I'm new to Windows programming and found that lots of prebuilt libraries for Windows offer libraries like lib-mingw, lib-vc2019, lib-vc2017...
Could anyone help to point out
what is the difference? Which library should I use in what case?
If I want to use Clang on Windows, which one should I use?
Why these different libraries rarely seen on Linux (let's say
Ubuntu), does package managers like apt hide this detail? In other word, why there's no such thing like lib-gcc.a, lib-clang.a on Linux platform?
Mingw (GCC), VC2019 and VC2017 are different compilers. Use the library corresponding to your compiler.
I'm not sure but I think none of them will work with Clang. At least on Linux GCC and Clang are very similar. I mean they are mostly binary compatible, many same compiler flags, many same compiler extensions. Clang tried to make it possible to easily replace GCC in your build pipeline. But all these information is for Linux.
These libraries are not seen on Linux because all these compilers are Windows compilers
You can always build a library with your compiler to use it in your project with your compiler (if you have the sources).
If it's a third party closed source library and you are a paying customer you can ask if they build it for you. It's usually better the add a new compiler to the build pipeline than to lose a customer.
I've recently become interested in learning more about parallel computing, concurrency, etc. My main language is C++, so obviously I decided to use that in my personal studies.
After some research (read: looking things up on Google), I decided that using Intel's TBB library would be the most ideal.
The one thing that's got me stuck so far, though, is setting it up to use on my computer. I have looked on the Internet for some sort of tutorial on setting TBB up with MinGW (in my case, specifically Nuwen) and haven't really found anything.
So, here's my question: how would I set up TBB to use with a Nuwen distro?
TBB doesn't provides binaries for mingw in a Windows package. So you should build it from source code. You need compiler and GNU make;
Download source code(.zip) from https://github.com/01org/tbb/releases
Unpack somethere (not sure, but in common: beware of spaces in the dir path)
Open your console with compiler's environment, go to $archive_root/src and call gmake tbb tbbmalloc compiler=gcc. Also you could try to add stdver=c++11 in the build command if your complier supports this mode.
You will find a library build in the $archive_root/build/windows_... directory
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I used to program in Windows with Microsoft Visual C++ and I need to make some of my portable programs (written in portable C++) to be cross-platform, or at least I can release a working version of my program for both Linux and Windows.
I am total newcomer in Linux application development (and rarely use the OS itself).
So, today, I installed Ubuntu 10.04 LTS (through Wubi) and equipped Code::Blocks with the g++ compiler as my main weapon. Then I compiled my very first Hello World linux program, and I confused about the output program.
I can run my program through the "Build and Run" menu option in Code::Blocks, but when I tried to launch the compiled application externally through a File Browser (in /media/MyNTFSPartition/MyProject/bin/Release; yes, I saved it in my NTFS partition), the program didn't show up.
Why? I ran out of idea.
I need to change my Windows and Microsoft Visual Studio mindset to Linux and Code::Blocks mindset.
So I came up with these questions:
How can I execute my compiled linux programs externally (outside IDE)?
In Windows, I simply run the generated executable (.exe) file
How can I distribute my linux application?
In Windows, I simply distribute the executable files with the corresponding DLL files (if any)
What is the equivalent of LIBs (static library) and DLLs (dynamic library) in linux and how to use them?
In Windows/Visual Studio, I simply add the required libraries to the Additional Dependencies in the Project Settings, and my program will automatically link with the required static library(-ies)/DLLs.
Is it possible to use the "binary form" of a C++ library (if provided) so that I wouldn't need to recompile the entire library source code?
In Windows, yes. Sometimes precompiled *.lib files are provided.
If I want to create a wxWidgets application in Linux, which package should I pick for Ubuntu? wxGTK or wxX11? Can I run wxGTK program under X11?
In Windows, I use wxMSW, Of course.
If question no. 4 is answered possible, are precompiled wxX11/wxGTK library exists out there? Haven't tried deep google search.
In Windows, there is a project called "wxPack" (http://wxpack.sourceforge.net/) that saves a lot of my time.
Sorry for asking many questions, but I am really confused on these linux development fundamentals.
Any kind of help would be appreciated =)
Thanks.
How can I execute my compiled linux
programs externally (outside IDE)? In
Windows, I simply run the generated
executable (.exe) file
On Linux you do the same. The only difference is that on Linux the current directory is by default not in PATH, so typically you do:
./myapp
If you add current dir to the path
PATH=".:$PATH"
then windows-like way
myapp
will do, but this is not recommended due to security risks, at least in shared environments (you don't want to run /tmp/ls left by somebody).
How can I distribute my linux application?
In Windows, I simply distribute the executable files with the corresponding DLL files (if any)
If you are serious about distributing, you should probably learn about .deb (Ubuntu, Debian) and .rpm (RedHat, CentOS, SUSE). Those are "packages" which make it easy for the user to install the application using distribution-specific way.
There are also a few installer projects which work similarly to windows installer generators, but I recommend studying the former path first.
What is the equivalent of LIBs (static library) and DLLs (dynamic library) in linux and how to use them?
.a (static) and .so (dynamic). You use them in more or less the same way as on Windows, of course using gcc-specific compilation options. I don't use Code::Blocks so I don't know how their dialogs look like, in the end it is about adding -llibrary to the linking options (guess what: on windows it is about adding /llibrary ;-))
Is it possible to use the "binary form" of a C++ library (if provided) so that I wouldn't need to recompile the entire library source code?
Yes. And plenty of libraries are already present in distributions.
Note also that if you use .deb's and .rpm's for distribution, you can say "my app needs such and such libraries installed" and they will be installed from the distribution archives. And this is recommended way, in general you should NOT distribute your copy of the libraries.
If I want to create a wxWidgets application in Linux, which package should I pick for Ubuntu? wxGTK or wxX11? Can I run wxGTK program under X11?
Try wxGTK first, dialogs may look better, gnome themes should be used etc.
If question no. 4 is answered possible, are precompiled wxX11/wxGTK library exists out there? Haven't tried deep google search.
Try
apt-cache search wx
(or spawn your Ubuntu Software Center and search for wx)
In short: you will find everything you need in distribution archives.
Navigate to the folder with your compiled program and execute ./program
Send the program, plus any .so files
.a is static library, .so is shared libraries.
Yes, but often you need to compile it yourself first.
Not sure about wxWidgets distributions, though.
Since Ubuntu comes with wxGTK packages you should definitely build against them. For development you should use a debug version though, so it might be good to build yourself, but for deployment building against the packages the system provides seems better.
wxX11 is a worse choice than wxGTK, use it only for systems where wxGTK doesn't exist or requires newer GTK libraries than are available.
Why not just stick with what you know and develop in .NET? Ubuntu comes native with Mono. You could keep using Visual C++ or step up to C# and make your life a whole lot easier.
A piece of general advice to Linux newcomers, but who are technically minded to begin with, is: You should learn to use your chosen distribution properly.
In your case, that means learning how to acquire the right development packages provided by Ubuntu. For instance, some other people are advising you to download the source for libraries you are going to use, but the better way is to use Ubuntu's package system to download the libraries you want to program against, together with the headers for that library (often put in a separate package) as well as the debug symbols for the library (also often in a separate package).
Look in the System->Administration menu in Ubuntu for the Synaptic tool, which allows you to search the package repositories on the Internet. You'll almost certainly find packages for the libraries you need, as well as all tools.
1, Unix generally doesn't have a particular extension for an executable - so myprog.exe would just be myprog.
You might have to set it to be executable if the IDE doesn't do this automatically, type "chmod +x myprog"
5, For wxWindows I would download the source and build it, check the build instructions but it's probably just a matter of "configure;make;make install". Generally in Unix you build libs form source so that they can correctly find all the components on your machine - you also have the source of examples etc.
I just added some information to rlbond's answer.
It is depens on Linux version. If you use a Ubuntu - create a deb-package. (http://ubuntuforums.org/showthread.php?t=51003)
Can I run wxGTK program under X11?
Yes, if you have wxGTK package installed :)
This is not really going to answer your questions, but I think is a valid recommendation.
You have two issues you are trying to deal with:
The Linux environment.
Making sure your program is
portable.
If I were you I would load CodeBlocks on Windows and run against either Cygwin or Mingw, that will help you make sure your code is portable across platforms. You are familiar with the environment and would gain maximum productivity getting over the OS hurdle.
Once you are satisfied with the above then take your code and move it to Linux. At that point any porting effort should be trivial.
When you say your program didn't show up I assume you mean that it was there in the file browser but when you double clicked it you got a busy cursor for a moment and then nothing happened?
If so then it means that the program failed to run, probably because it couldn't find the dynamic libraries it's linked against. To diagnose the problem you can run it from a terminal and then you'll be told what the problem is.
You might want to read the manual page for ld.so i.e. type
man ld.so
into a terminal. This tells you where the Linux dynamic library linker looks for libraries at run-time. It also refers you to another useful tool called ldd which I recommend becoming familiar with if your are doing Linux development.
Is it possible to use shared object files in a portable way like DLLs in Windows??
I'm wondering if there is a way I could provide a compiled library, ready to use, for Linux. As the same way you can compile a DLL in Windows and it can be used on any other Windows (ok, not ANY other, but on most of them it can).
Is that possible in Linux?
EDIT:
I've just woke up and read the answers. There are some very good ones.
I'm not trying to hide the source code. I just want to provide an already-compiled-and-ready-to-use library, so users with no experience on compilation dont need to do it themselves.
Hence the idea is to provide a .so file that works on as many different Linuxes as possible.
The library is written in C++, using STL and Boost libraries.
I highly highly recommend using the LSB app / library checker. Its going to tell you quickly if you:
Are using extensions that aren't available on some distros
Introduce bash-isms in your install scripts
Use syscalls that aren't available in all recent kernels
Depend on non-standard libraries (it will tell you what distros lack them)
And lots, upon lots of other very good checks
You can get more information here as well as download the tool. Its easy to run .. just untar it, run a perl script and point your browser at localhost .. the rest is browser driven.
Using the tool, you can easily get your library / app LSB certified (for both versions) and make the distro packager's job much easier.
Beyond that, just use something like libtool (or similar) to make sure your library is installed correctly, provide a static object for people who don't want to link against the DSO (it will take time for your library to appear in most distributions, so writing a portable program, I can't count on it being present) and comment your public interface well.
For libraries, I find that Doxygen works the best. Documentation is very important, it surely influences my choice of library to use for any given task.
Really, again, check out the app checker, its going to give you portability problem reports that would take a year of having the library out in the wild to obtain otherwise.
Finally, try to make your library easy to drop 'in tree', so I don't have to statically link against it. As I said, it could take a couple of years before it becomes common in most distributions. Its much easier for me to just grab your code, drop it in src/lib and use it, until and if your library is common. And please, please .. give me unit tests, TAP (test anything protocol) is a good and portable way to do that. If I hack your library, I need to know (quickly) if I broke it, especially when modifying it in tree or en situ (if the DSO exists).
If you'd like to help your users by giving them compiled code, the best way I know is to give them a statically linked binary + documentation how they can run the binary. (This is possibly in addition to giving the source code to them.) Most statically linked binaries work on most Linux distributions of the same architecture (+ 32-bit (x86) statically linked binaries work on 64-bit (amd64)). It is no wonder Skype provides a statically linked Linux download.
Back to your library question. Even if you are in an expert in writing shared libraries on Linux, and you take your time to minimize the dependencies so your shared library would work on different Linux distributions, including old and new versions, there is no way to ensure that it will work in the future (say, 2 years). You'll most probably end up maintaining the .so file, i.e. making small modifications over and over again so the .so file becomes compatible with newer versions of Linux distributions. This is no fun doing for a long time, and it decreases your productivity substantially: the time you spend on maintaining the library compatibility would have been much better spent on e.g. improving the functionality, efficiency, security etc. of the software.
Please also note that it is very easy to upset your users by providing a library in .so form, which doesn't work on their system. (And you don't have the superpower to make it work on all Linux systems, so this situation is inevitable.) Do you provide 32-bit and 64-bit as well, including x86, PowerPC, ARM etc.? If the .so file works only on Debian, Ubuntu and Red Hat (because you don't have time time to port the file to more distributions), you'll most probably upset your SUSE and Gentoo users (and more).
Ideally, you'll want to use GNU autoconf, automake, and libtool to create configure and make scripts, then distribute the library as source with the generated configure and Makefile.in files.
Here's an online book about them.
./configure; make; make install is fairly standard in Linux.
The root of the problem is that Linux runs on many different processors. You can't just rely on the processor supporting x86 instructions like Windows does (for most versions: Itanium (XP and newer) and Alpha (NT 4.0) are the exceptions).
So, the question is, how to develop shared libraries for Linux? You could take a look at this tutorial or the Pogram Library Howto.
I know what you are asking. For Windows, MSFT has carefully made the DLLs all compatible, so your DLLs are usually compatible for almost every version of Windows, that's why you call it "portable".
Unfortunately, on Linux there are too many variations (and everyone is thinking to be "different" to make money) so that you cannot get same benefits as Windows, and that's why we have lots of same packages compiled for different distributions, distro version, CPU type, ...
Some say the problem is caused by (CPU) architecture, but it is not. Even on same arch, there's still different between distributions. Once you've really tried to release a binary package, you would know how much hard it is - even C runtime library dependency is hard to maintain. Linux OS lacks too much stuff so almost every services involves dependency issue.
Usually you can only build some binary that is compatible to some distribution (or, several distributions if you are lucky). That's why releasing Linux programs in binary always screwed up, unless bound to some distro like Ubuntu, Debian, or RH.
Just putting a .so file into /usr/lib may work, but you are likely to mess up the scheme that your distro has for managing libraries.
Take a look at the linux standard base - That is the closest thing you will find to a common platform amongst linux distros.
http://www.linuxfoundation.org/collaborate/workgroups/lsb
What are you trying to accomplish?
Tinkertim's answer is spot on. I'll add that it's important to understand and plan for changes to gcc's ABI. Things have been fairly stable recently and I guess all the major distros are on gcc 4.3.2 or so. However, every few years some change to the ABI (especially the C++ related bits) seems to cause mayhem, at least for those wanting to release cross-distro binaries and for users who have gotten used to picking up packages from other distros than they actually run and finding they work. While one of these transitions is going on (all the distros upgrade at their own pace) you ideally want to release libs with ABIs supporting the full range of gcc versions in use by your users.
Does anyone have any experience with running C++ applications that use the boost libraries on uclibc-based systems? Is it even possible? Which C++ standard library would you use? Is uclibc++ usable with boost?
We use Boost together with GCC 2.95.3, libstdc++ and STLport on an ARMv4 platform running uClinux. Some parts of Boost are not compatible with GCC 2.x but the ones that are works well in our particular case. The libraries that we use the most are date_time, bind, function, tuple and thread.
Some of the libraries we had issues with were lambda, shared_pointer and format. These issues were most likely caused by our version of GCC since it has problems when you have too many includes or deep levels of template structures.
If possible I would recommend you to run the boost test suite with your particular toolchain to ensure compatibility. At the very least you could compile a native toolchain in order to ensure that your library versions are compatible.
We have not used uClibc++ because that is not what our toolchain provider recommends so I cannot comment on that particular combination.
We are using many of the Boost libraries (thread, filesystem, signals, function, bind, any, asio, smart_ptr, tuple) on an Arcom Vulcan which is admittedly pretty powerful for an embedded device (64M RAM, 533MHz XScale). Everything works beautifully.
GCC 3.4 but we're not using uclib++ (Arcom provides a toolchain which includes libstd++).
Many embedded devices will happily run many of the Boost libraries, assuming decent compiler support. Just take care with usage. The Boost libraries raise the level of abstraction and it can be easy to use more resources than you think.
I googled "uclibc stlport". It seems there are at least a few versions of uclibc for which stlport can be compiled (see this).
Given that, i'd say Boost is just a few compilation steps away. I have read a message by David Abrahams (who is an active member of the boost community) that says that Boost does not depend directly on the used libc. But some libraries may still cause problems, Boost.Python for instance, since it depends on something else (Python in my example) that might be difficult to compile with uclibc.
Hope this helps
I have not tried but I don't know anything about uclibc that would prevent Boost from working.
Try it and see what happens, I would say.
Yes you can use boost with uclibc.
I tried this with boost 1.45 & uclibc on ARM9260
Use fresh OpenEmbedded
Configure it to use Angstrom
Configure Angstrom to use uclibc
make boost - bitbake boost