EDIT: thread obsoleted by http://board.flatassembler.net/topic.php?t=6600

As the title says, there is finally an overlay for the portage, it's written by me and is currenlty eXPerimental, but it works for me (if that makes anyone feal eaiser at heart).

For all those of you who don't use gentoo or haven't heard of it, I'm sorry, but I don't have time to explain it now (if you want one, feel free to ask for it - and I'll see if I can find time).

The steps to make the dream "emerge fasm" real are as follows:

(you probably have to be root in a few of the steps)

1. Download the file OBSOLETT URI , save it somewhere (/tmp is good if you're not sure where to put it).
   
2. run "mkdir /usr/local/portage/dev-lang/ -p" to create the needed dirs. Then cd to it ("cd /usr/local/portage/dev-lang/").
   
3. now, we're gonna extract the goodies (namley the ebuild, digest, maifest and two optional patches), type: "tar xvfj /path/to/the/downloaded/attachment/fasm.overlay-XP-r3.tbz2".
   
4. Now, we're all getting that nice feeling of expectation, neh? Relax we're almost done. fire up your favourite text editor (mine is emacs, someothers prefer vim, and some gedit) and open /etc/make.conf (you'll need to be root to do this, if not, you're in trouble...). add the following line to the file:
   Code:

   PORTDIR_OVERLAY=/usr/local/portage    

   save and exit the editor.
   
5. Now you should be ready to rock 'n' roll, type: "emerge -Dpv fasm" (harmless command, won't do anything but show some text) in a termninal of choice

you're gonna see a screen looking something like this:

Code:

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] dev-lang/fasm-1.56  -fasm_permissions -libc* -rebuild* 0 kB [1] 

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage    

if you simply want the "vanilla" version of fasm, that is the regular version you'd get from downloading it directly from this site, just type (as root): "emerge fasm"

if you wonder what "-fasm_permissions -libc* -rebuild*" is all about, it's just three USE options, usually you don't need to play with this, but if you do you know how to use it (either via USE="..." emerge ... or the "correct" /etc/portage/package.use), I'll give a short explanation over the flags meaning:

• fasm_permissions will apply a patch which adjusts the permissions of the assembled output, I've made some noise about it some time ago - just an modificatipn of personal taste.
  
• libc this is the famous libc patchset of fasm, though, forward-ported from version ~1.5[2-4] (not sure which one, couldn't find version number in the files). I've used libc on my 64-box, seems to work. note: libc and fasm_permissions are mutually exclusive, haven't (yet) taken time to make the needed adjustment on the libc version. (emerge will fail with both given)
  
• rebuild simply forces a rebuild of fasm, libc and fasm_permissions implies this one.

Note for all of use using amd64: we must ACCEPT_KEYWORDS="~amd64" (or the "correct" way, using /etc/portage/package.keywords) - this is since I'm not sure how the 32-bit version works in long mode (seems to work anyway).

if anyone of you try this, please post and say how it works - ie not just "it doesn't work"-posts but also, "yes it works for me too"-posts.

I don´t use Gentoo, but i voted yes anyway (any sharing is good), so if you could be so kind and add a explaination when you have more time.

hello there!

how about autopackage for FASM?
http://www.autopackage.org/

--

ok, so far a 6:0 ratio for maintaining it

Ok, here is a short introduction to Gentoo and the portage:
Gentoo is yet another distrobution of linux, so what's so special about it? The short answer is, the whole shebang.
When you're about to install gentoo you're give 3 possible starting points, so called "stages", there are 3 stages:

• Stage 1 - here you compile every single package that will become your system, this includes the whole toolchain (gcc, and the other basic tools), boot loader, system logger, window manager, x-server, everything
  
• Stage 2 - this step is the one which occurs after the so called "bootstrap", you're almost compiling everything your self.
  
• Stage 3 - most of the hard work is already done, at the expense of limiting some of your "freedome of choice"

( for a more detailed description of the stages and a summary of pros and cons of the different steps, se
http://www.gentoo.org/doc/en/handbook/2004.2/handbook-x86.xml?part=1&chap=2 or http://www.gentoo.org/doc/en/handbook/2004.2/handbook-amd64.xml?part=1&chap=2 )

The so called portage is the "heart" of gentoo, it is primarily know as the "emerge" command (which reall is just one part of it). The portage is a list of +8000 packages (and still growing) which more or less can be emerged/installed by simply typing "emerge app-name" and striking enter.
The beauies of emerge are many, but to give one example:
You want a web-browser, and you think firefox is your way to go (the so called ebuild for firefox is named "mozilla-firefox"), you can type "emerge mozilla-firefox" and just go with it but with firefox you got a rare choice (, since most apps are avalible as source only installs), "mozilla-firefox" or "mozilla-firefox-bin", mozilla-firefox-bin is a precompiled relese of firefox, and if you don't got a fast system you might want to choose that (note, you'll not have much optimizations in it then). I've chosen "mozilla-firefox", and thus compiled it from scratch, with (rather agressive) optimizatons for my amd64. We say we're on a fast system and thus got with having emerge get the source and build it all for us and install it (yes, beauty #1, emerge handles this transparantly, just a command and it's installed).
So now we've run "emerge -Dv mozilla-firefox" ('-Dv' adds some verbosity and also makes sure depencies are checked - more on that later) and we've waited for it to finnish and used firefox some time, and we now think there is a neweer version of firefox ready for us, so naturally we want to keep up2date, first we see if there is any update avalible, we type "emerge -Dpv mozilla-firefox" and hit enter, and we might see something like:

(note this example output is partially fictive, and just to show an example)
This tells us that there infact is a newer version of firefox avavlible, version 1.0, "-r3" likley means that the ebuild (information for emerge on how to install the app) has changed, there might be some bug fixes it applies to the source before building it, "[1.0]" is the currently installed version. From this we see that running "emerge -Dv firefox" will update firefox (not just re-install it as it would if there be no uppgrade avalible).
But you might notice the to lines starting with "[ebuild N", those are depencies that firefox needs, the "N" means that they're new, if it'd be an "U" instead of "N" it simply means there's a newer version of them avalible, and firefox needs them). That's beauty #2, depencies are automatically installed to, and updated if there be need.
So we run "emerge -Dv mozilla-firefox" and we're uppgrading firefox and the two depencies.

You might think, "but what if I want my whole system up2date, do I have to manually check all apps?" - teh answer is no, there is a speciall emerge "app":
"emerge world" in it's shortest form, it sort of means "update all apps I've installed if there is an update, else ignore that app". When I do a world emerge I add a few more options:
"emerge -Dpvu --newuse world" - which sort of says "show me any packages that can be uppdated or if the options for installing them has changed since I installed it", ie "update anything that can be done". after I've checked the packages it can emerge I usually just strip the "p" and run the command again and let it fetch and install it.

ok, that was a "short" explanation of it, but imo, you might be better of reading the following docs, the first two are short one page texts, the last the "handbook" isthe big documentation, avalible in many languages, formats and for different archs.

http://www.gentoo.org/main/en/about.xml
http://www.gentoo.org/main/en/philosophy.xml
http://www.gentoo.org/doc/en/handbook/index.xml


autopackage, looks nice, but I don't think I can take that on my shoulders too.

Well, I tried once to install Gentoo and actually without any success.
After this I understand why I don't like Linux - because I like checkboxes instead of --SomeVerySmartOptions console keys After that I installed Ubuntu distribution without any troubles.

Don't get me wrong, your work with FASM is great and FASM deserves to be more popular in Linux world.

Regards

Try it again

It worth every minute you spend on it. You'll have a "living" system completely updated to take advantage of your particular hardware configuration.

oops, I've made a little error - it's a permissions issue, as usual, the permissions are abit too strict... (ie only root had access to any files but /opt/fasm/fasm (rebuilt version))

just extract the tarball bellow, _instead_ of the one attached in the first post, as in the instructions in my first post - for those who installed with the first ebuld, just type:
"emerge fasm" after extracting the tarball - it'll uppgrade and fix the permissions (note if you specified any USE flags you'll need to specify them again).

beauty #3: this update uses the fasm-1.56 tarball, even if the ebuild says it's version 1.56-r2 (r2 = release 2).

I'm sorry for the inconveience...

I'm doing my best to spread fasm in the linux world, though, I'm not that good on making ebuilds for them to end up in the official portage (they got all sorts of rules and such, eg everything must be marked unstable for at least 2 months before considered "stable" per portage policy).

JohnFound, imo, a stage 1 gentoo install is really quite easy (read: if you're a complete nut case like me and not afraid of the freedome of choice ) if you stick to the manual and follow then steps to the letter - I hope I'll get enought time in the future to help make a port of fresh to linux
(haven't tried the latest wine with fresh, so I don't know how it looks atm)


did the attachment break? (I'll uppload the file to another place - post url soon)

EDIT: obsolete, se later posts
here's the file: OBSOLETE URI
(updating first post to void confusion)

Great work. I appreciate it, since Gentoo is actually the only one Linux distro I really like.
Do you think it would be hard to make it into the official portage tree? (hmm, is Bazik still busy with the army?)

well, first I'm concerned with one "major detail issue", one of the requirements of "official" ebuilds are that the file contains a LICENSE="" line follows this:

My understanding is that the fasm license is the revised BSD, correct? The problem is that I only find "BSD" in the dir with licenses, it seems it's the "unrevised" BSD license, which will either lead to the revised having to be added or fasm's license file be added to the license list. - maybe it'd be better to ask the gentoo wizzards on what is best.

Also, I'd have to tidy up the ebuild's a bit and read up some more on the rules for official ebuilds. So it's not impossible, it just a matter laziness and time
I belive it'd be wonderfull for fasm to be in the official tree, so a short and honest answer to the question if it'd hard to get it in there is: I don't really, know, but I can look in to it if you want (I've already begun reding the docs on it)

btw, I'm happy to say that it seems like fasm works fine running on and amd64 (it runns as an 32-bit app, due to emulation). Though, as the libc version is a forward patch (meaning it's not fuly uptodate with non libc specific stuff) I'm (a little) concerned about some of the variables in it - first time I compiled it with the patch I got an error about some prefix variable, byte size --I simply cut'n'paste the variable definition from Linux/fasm.asm-- and a quick look gave a few diffs in the variables between source/Linux/fasm.asm and source/libc/fasm.asm - iirc one was about some _origin variable beeing dd in one file and dq in the other - could you please just take a quick look and post (or email me) the corrections? It seems to work now, but I haven't ran any biggers tests on the libc patched version (I'm using it on this machine to test it atm).

haven't seen Bazik for a long time now :/

The license fasm uses is the so called 2-clause BSD-like license, there are some additional phrases added into it, but they are more like comments and explanations - the license clauses (two of them) and disclaimer are exactly the same as in original BSD license. If I added the third clause, which is:

it would be revised BSD license (the original BSD contained four clauses, the additional one related to advertising).
I think that adding the third clause wouldn't hurt me much so I can revise the fasm license to become revised BSD - to make things simpler. And I think that probably (but it's better to ask some Gentoo developers) the BSD license they list is the revised one, since only the revised one is OSI-approved.

ok, I'll find a gentoo dev to bug
just for fun reading, here's the 2 BSD licences, seems "BSD-protection" is quite new - haven't checked the diff between that and BSD
http://web.telia.com/~u36404088/fasm/BSD
http://web.telia.com/~u36404088/fasm/BSD-protection

btw, kinda off topic, I geuss you've seen this site, but I figgure it wont hurt to post a link:
http://www.x86-64.org/documentation/assembly
one interesting thing they mention is "movl $0x1, 0x10(%rip)" - I belive the fasm/intel syntax will make that "mov [rip+10h], 1"

does this make "mov [rip+symbol], 1" the same as "mov [symbol], 1" but using a smaller encoding?

This is one of the problems that slowed down the development of AMD64 code generation capable fasm - I'm trying to find a good solution for the memory operand syntax and encoding. AMD64 architecture doesn't allow 64-bit immediates (with only a few exceptions, like "mov eax,[address64]"), only 32-bit one, but at the same time it allows RIP-relative addressing. So instruction "add eax,[$]" would be encoded with absolute addressing only for $ values below 4 GB, but would be also encoded as "add eax,[rip+0]". It would be better for fasm to use the second variant when possible (and you wouldn't have to use the "rip" keyword at all). I have almost completed a good solution for it, and then the first fasm64 will be near to be finished.

I'm just chatting with a gentoo dev on irc, and it seems to be best to have the fasm license added to the 451 existing licenses.

how about (just brainstorming a few different suggstions):

well, "It would be better for fasm to use the second variant when possible", that would fit with the general fasm way right? (smallest when possible). and if someone wants to 'force' another way, well there's 'db' and marcros

And this wouldn't completely fit with the general fasm way - I tried to always provide some overrides to allow coder to control size of immediates, etc.
The overrides for memory operand are currently provided inside the square brackets (like "add eax,[dword 0]"), so any prefixes for relative addressing would have to be provided this way, too.

Oh, and as for the libc version, it is enough to copy all the data definitions as they are in Linux version starting from the "memory_setting" variable up to the end of file and replace the ones that are in old port.

ok, I'll make the adjustments to the patch.

ok, here's the update:
OBSOLETE URI

(edit: obsolete post)

long time no coding... well, here's an ebuild for 1.67.7
here's instructions on how to make use of it, sorry, no fancy tarball this time :/

Can't wait when fasm will be in portage.

Gentoo + Fasm =