Hi all, Thanks Martin for the answer. Right now I'm trying to port a static library which I think involves a similar procedure to the one needed to export an app. Based on Vojta's blog on how to port apps I'm trying to start porting a static version of zlib and then a static version of libpng. I started using the coastline but it gives some errors, so since the porting of zlib should be fairly simple (I'm doing it for ia32) I resorted to the previous script (i.e. configure-for-helenos.sh.) The thing is that when I execute the make, after invoking the script with the proper arguments (the ones from the blog), it gives me the following error msg:
/usr/local/cross/ia32/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../i686-pc-linux-gnu/bin/ld: example: could not find output section .gnu.version_r It looks like something is missing. Could you give me a hint on what can it be? Thanks in advance. Cheers, Esteban 2014-03-03 11:33 GMT-03:00 Martin Decky <[email protected]>: > Hello Esteban, > > > Since I'm new at porting code I have a couple of questions: >> The idea would be 'rewrite' the code in order for it to use the subset >> of C supported by HelenSO right? >> > > If such changes would be minimal and well contained (e.g. in a rather > small patch that could be applied automatically on the upstream sources), > changing the upstream source tree is fine. On the other hand, you probably > don't want to fork a wildly diverge the upstream libpng. Having such a > diverged libpng would be of little benefit compared to writing our own PNG > library. > > If you expect the required changes in libpng to be substantial, you should > choose the other path -- extend the HelenOS native libc or the libposix > compatibility library by functions that are required by linpng. > > Generally speaking it is really a matter of taste whether you prefer > changing the ported library or extending the environment. But the ultimate > goal should be the same in both cases: A clean and well-designed solution. > > > In that case I have another doubt, the library contains some files >> which easily exceed the 3K lines. This kind of task is generally done by >> inspecting line by line or some kind of automation can be achieved? >> > > The basic automation is based on link-time checks. If the library can link > with the environment (libc, libposix), there is a reasonable chance that > the environment will behave with respect to the library as expected > (although there might be subtle differences, especially in corner cases > (*)). You should use the test suite of libpng then to check for the > behaviour compliance. > > If these automated steps fail you would have to resort to manual > inspection of the code. > > (*) HelenOS is not POSIX compliant. Even the libc functions that have > POSIX-similar names are not guaranteed to behave in a POSIXly compliant way > (but they should behave reasonably). Even the functions in libposix are not > guaranteed to be 100% POSIX compliant (since they might be unfinished). The > keyword is "best effort" :) > > > M.D. > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
