hi there
if you release another version on www.openclonk.org, could you provide the source code too on the same page in an extra package?
something like "openclonk-5.1.1.3-src.tar.gz"
this way one can build its own binarys without having to learn about mercurial
if you release another version on www.openclonk.org, could you provide the source code too on the same page in an extra package?
something like "openclonk-5.1.1.3-src.tar.gz"
this way one can build its own binarys without having to learn about mercurial
Just out of curiosity: Why would you want to build an "own" binary if there are already binaries provided?
like, when you whant it to compile against libs that are already installed in your system, this way, you dont need to link them staticaly
or, if the binary where compiled against older libs, like with libpng12, with the source provided you could easely compile 5.1.1.3 for libpng14.
also, using the prebuild binarys, i need to install a package called "openssl-compatibility" on Archlinux because clonk refuses to work with the normal openssl libs provided by the ArchLinux package
or, if the binary where compiled against older libs, like with libpng12, with the source provided you could easely compile 5.1.1.3 for libpng14.
also, using the prebuild binarys, i need to install a package called "openssl-compatibility" on Archlinux because clonk refuses to work with the normal openssl libs provided by the ArchLinux package
> you dont need to link them staticaly
Why is this bad? (with "you", you mean us in this case, right?)
> if the binary where compiled against older libs, like with libpng12, with the source provided you could easely compile 5.1.1.3 for libpng14.
Why is this better? (with "you", you mean yourself in this case, right?)
> i need to install a package called "openssl-compatibility"
Hmm, I thought the dependencies were statically linked. Can somebody eludicate me?
By Anonymous ![[de]](/mwf/flags/de.png "Germany")
Date 2011-01-03 09:41
i think we both do agree that the problem is my spelling, i try to enunciate it the best way i can this time.
$you = "a random person, maybe a group of people with no defined attributes keeping these persons as random as it is possible"
i am more the casual coder so im sorry in advance if im stating something wrong here:
why is it bad to link librarys staticaly?
-oh, it actualy isnt, but in my experiense some $you could sometimes have problems with the given librarys, given the choice of using precompiled binarys OR compiling it themsels $you could MAYBE avoid these sort of problems, not that i say that this will occur, its just an example.
why is it better to compile something against a newer version of a given library?
-it again, doesnt need to be BUT in my case, my distribution comes with libpng14 wich whont work with the precompiled binarys, atleast, it didnt when i tried it, it is possible that i just made something wrong, these things happen.
when $you would have the source $you could easy compile the latest stable against these newer version of libs since MOST of the time (most, not everytime) these work just as the older version did.
its not that easy to get older versioned libs as an unexperienced user, that is one reason why i whant to create a packege for the latest stable of this great game.
about the openssl-compat. stuff?
-this is because
./clonk: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
the named lib that doesnt exist there is a openssl lib, it is again older then the version i have on my system, compatibility packs like openssl-compat. or the package i use to get libpng12 fix these problem but are imho not the best way to solve these kind of problems.
given the source $you could compile the binary against the newer libcrypto.so too.
i hope i answered most of your questions proberly
$you = "a random person, maybe a group of people with no defined attributes keeping these persons as random as it is possible"
i am more the casual coder so im sorry in advance if im stating something wrong here:
why is it bad to link librarys staticaly?
-oh, it actualy isnt, but in my experiense some $you could sometimes have problems with the given librarys, given the choice of using precompiled binarys OR compiling it themsels $you could MAYBE avoid these sort of problems, not that i say that this will occur, its just an example.
why is it better to compile something against a newer version of a given library?
-it again, doesnt need to be BUT in my case, my distribution comes with libpng14 wich whont work with the precompiled binarys, atleast, it didnt when i tried it, it is possible that i just made something wrong, these things happen.
when $you would have the source $you could easy compile the latest stable against these newer version of libs since MOST of the time (most, not everytime) these work just as the older version did.
its not that easy to get older versioned libs as an unexperienced user, that is one reason why i whant to create a packege for the latest stable of this great game.
about the openssl-compat. stuff?
-this is because
./clonk: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
the named lib that doesnt exist there is a openssl lib, it is again older then the version i have on my system, compatibility packs like openssl-compat. or the package i use to get libpng12 fix these problem but are imho not the best way to solve these kind of problems.
given the source $you could compile the binary against the newer libcrypto.so too.
i hope i answered most of your questions proberly
For the time being: http://hg.openclonk.org/openclonk/archive/openclonk-release-5.1.1.tar.bz2
thank you isilkor, is this really the version 5.1.1 or can i play on the web against users with 5.1.1.3 clients too?(does the clients need to be on the same version anyway?)
EDIT
im sorry, this IS 5.1.1.3, atleast Version.txt states this
EDIT
im sorry, this IS 5.1.1.3, atleast Version.txt states this
I have this on my (imaginary) TODO list already. There are few things that need to be taken care first of however: Ideally when building from tarball you can then run make install to install the package. Here is some work on that. Also, when building from tarball we need to hardcode the hg revision it was created from into Version.txt since it cannot de deduced by running hg --id anymore.
At this point, I want to mention the rough download statistics:68% Windows
26% Windows 64bit
6% Linux
$you could, ofcourse, use the source on windows too, i dont got much experience in compiling windows applications but i think $you need something like mingw or such.
downloading a packed source would provide $you with the source of the latest stable without finding out wich hg snapshot the latest stable is.
and actualy, i think 6% Linux users isnt that bad at all, watch some OS usage statistics on the web and you get a vague feeling about how much wich OS is used.
a script could control the packaging of a stable source.
while releasing a new version, calling the script while passing him a version number and a hg revision could pack a tar.gz or zip file with just one command, no additional input needed, ofcourse, someone need to script it first, i would do that if you let me.
it could be some sort of php script BUT i dont know if you can checkout a mercurial database with php.
it could be a shell script, this way you just need tar mercurial and probably some basic tools like wget or something.
a shell script could be executed by the binary packer himself, this way you dont need to place it on the server or something, it would be easier to code too (imho).
all it needs to do is checkout the source, strip unneedet files, pack it and name it "$pkgname-$pkgver-src.tar.gz" and it could be uploaded, prefebly in the same folder where your releases reside, to find it more easy.
downloading a packed source would provide $you with the source of the latest stable without finding out wich hg snapshot the latest stable is.
and actualy, i think 6% Linux users isnt that bad at all, watch some OS usage statistics on the web and you get a vague feeling about how much wich OS is used.
a script could control the packaging of a stable source.
while releasing a new version, calling the script while passing him a version number and a hg revision could pack a tar.gz or zip file with just one command, no additional input needed, ofcourse, someone need to script it first, i would do that if you let me.
it could be some sort of php script BUT i dont know if you can checkout a mercurial database with php.
it could be a shell script, this way you just need tar mercurial and probably some basic tools like wget or something.
a shell script could be executed by the binary packer himself, this way you dont need to place it on the server or something, it would be easier to code too (imho).
all it needs to do is checkout the source, strip unneedet files, pack it and name it "$pkgname-$pkgver-src.tar.gz" and it could be uploaded, prefebly in the same folder where your releases reside, to find it more easy.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
