I believe I'm using bash, what is the default for gentoo installations?

I think the problem was that make was passing your command verbatum to g++ which would expect parameters with dashes and hit upon a (

about the escaping, thanks, I think I get it now. : ) Biggest problem was I didn't understand the tr command, now I see it expects 2 sets and the 2nd set was empty (i mean 1 space, but that confused me too )

But now that we digressed here, that last example last couple '' still confuses me (for a different reason now,lol).. after you placed the \n inside the string then you place 1 final ' into the string you wouldn't need to get back in the string, so the pattern '\'' dont need the last ', right? by doing this you enter the string again only to exit it (with the last ') but then wouldn't you miss the closing ' for the command? how come it works?

Yes, Bash is default. The last ' is needed because you want it to become tr '\n' ' '; that gets to be inside the quotes as 'tr '\n' ' '', and if you replace the ' inside by '\'' you get 'tr '\''\n'\'' '\'' '\'''.

The tr command just replaces the character of the first parameter by the second parameter; so, replacing '\n' by ' ' means that newlines will become spaces. Very useful to turn multiple lines into multiple parameters.

What I do not get is this.. we are going in and out of the command string which begins with echo, right? as in bash -c 'echo etc'

This last single quote (ending the string and thus the -c parameter) would be achieved after \n, but then our string would be missing a quote as in "... tr ' ' '\n ... "

.. we then add that one with \'... why isn't that enough? In fact, if I'm right it also explain why the command still works... i did not see this before but because the last 2 single quotes cancel each other.

inside the script I'd still have to close the parenthesis from $(bash -c ... so the line would end in \')

anyway, not important.. I'm about to test that version, brb with a report =)

Yep.. Sorry, the problem seem to be the $(bash -c '...') thing... I place a testing string to break the command on either side, and it produces nothing: (but it doesnt break the code either, the 2nd break still prints)

Edit: Our escaping adventures didn't pay off tr is getting a whole bunch of slashes...
Edit 2 Thats very confusing, I trying the command directly on the shell (it is indeed the escaping is off ), but the funny part is that it seems to get everything right, but the first single quote! then if I mess with stuff before the \n, it get's slashes after the \n.. look:

Apart from the intentional breakage; that looks good, but where did the -L /usr/lib/ parameter go?

It's being eaten by tr as tribute for my lack of escaping skillz (more details on the edits above)

edit btw, I could simply use the double quotes example you gave, it's probably safer.. but aren't you curious why this does not work? : )
edit 2: Just realized my tests above are invalid, they doesnt tell us much because I'm not inside a string to escape out of, as i am when inside $(bash -c '... sorry edit 3 ok, fixed my meta-mistake, placed inside a script by itself.. here is the true output

Code:

# ./test.sh
tr: missing operand after ‘n ’

That's more informative, It is not getting the single quotes in... Edit 4:Please ignore edit 3, it was one of the many tests i used, not the "official" string.. here is the output

Code:

# ./test.sh
./test.sh: line 1: -L/usr/lib/: No such file or directory

Which is weird because it prints the -L/usr/lib !

Last edited by MarcoMarin on Sun Apr 13, 2014 4:50 pm; edited 1 time in total

It is less common for me to type it this way, given that " usually denote strings whereas ' denote characters in programming languages; in languages and Bash and JS, I don't really know what is expected given that both are often possible.

the only thing I managed to discover is that spaces between variables and their values can break this...

I tried TEST123=$(bash -c 'etc') and it worked... with TEST123 =$... it tries to execute TEST123 (funny though, in the makefile it uses spaces! ).. then TEST123= $... it prints -L/usr/lib/, but also thinks it's a command and stops there because it's not a file or dir...
enclosing the = with spaces, just like the makefile manages to do, gives the same output as the first error above with 1 space before =...

I'm going for double quotes then... =/

edit oh, before i do that, i could simply use an intermediate variable! lets see...
edit 2 I think I know what's going on.. make doesn't seem to want to execute stuff.. I tried placing it in a variable of it's own, then I even separated the LIBS assignment with LIBS += $(INTERM) in a line of it's own, no luck either.. the only option now is hardcoding

You can remove those, that are the .a files which aren't the libraries themselves; in the original command, this can be solved by replacing libboost_* by libboost_*.so such that it only takes the .so files.

Seems to be working... copied over to a user's home account (dunno if it would work compiling as non-root.. was this unwise? lol).. didn't complain about anything (it is the executable alone), simply worked (then quitted due to some configuration problem, but it shows it works!)

Thanks TomWij!!! Really appreciate all the help!

Now the last step, compiling the Qt gui! Gonna give it a rest then read the readme for it, then report back what happens : )

Just a re-run of the same problems (and respective fixes thx!).. it probably compiles the daemon in as well, so it doesn't need to call the previous executable... (edit: except that the daemon is almost 60MB and the qt version is 10.8MB )

Anyway, awesome, took a while, about 2 months to set this box for this purpose but I learned a lot, thanks all. : )

A few strange, hopefully innocuous, stuff with this QT version of the wallet, Tom:

1) I tried running simply as #feathercoin-qt , it complained about miniupnp, not finding.. I was getting ready for another session here, when I tried ./feathercoin-qt and it worked! This probably means a previous experiment with that .deb package is in the system and I must remove it...

2) Just now it is synchronizing with the FTC network, then it pops up a warning which did not happen with LTC (same box, it is in portage though, so it was easier to get it working), nor did it ever happened before with BTC either (other machine though). The warning said to check the machine's clock or it would not work properly if it was wrong. But the clock is perfectly fine. If this pops up again, I'll begin to worry. lol

I'm probably too inexperienced to do it myself, but I hope our experience here in this thread can be of help to place the FTC client on portage together with LTC.