Re: R_X86_64_32S error building a shared library
On Mon, 26 Jan 2009, Adam Nielsen wrote: I think it must have been the way Boost was compiled, because I get the same error even when I don't link to any libraries: $ g++ -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared Note that with the above, main.o would need to be PIC code since it is being put in a shared library. But if I add -fPIC in that case, it works: $ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared This works since main.cpp is being compiled to main.o with PIC. However, Boost is not involved here so it proves nothing about Boost. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: blank line following trailing backslash
Hi, Andreas roe...@users.sf.net writes: I just had an ingenious idea to limit conflicts in versioning systems. When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c One slightly ugly-looking approach I've seen is EMPTY = foo_SOURCES = \ fileA.c \ fileB.c \ fileC.c \ $(EMPTY) - Hari
Re: blank line following trailing backslash
Hello Andreas, * Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET: fileA.c \ fileB.c \ fileC.c [...] This is not nice so I thought well let's add a backslash after the last file and add an empty line at the end. Then there's no need to modify the fileC line and everybody just adds a line to the list. This can be resolved. But automake doesn't like this at all. Even though it is clearly visible that this is not wrong it complains. It doesn't even warn about this it produces an error. Jan already provided a way around this. Here's why automake warns about it at all: it is not portable to have a backslash followed by a blank line, as some make implementations are rather unpredictable with it: http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewline_002dNewline.html http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewline-Comments.html Hope that helps. Cheers, Ralf
Re: blank line following trailing backslash
* Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET: fileA.c \ fileB.c \ fileC.c [...] I do it this way: NULL= ... FOO= \ fileA.c\ fileB.c\ $(NULL) BAR= \ fileC.c\ fileD.c\ $(NULL) Mostly I do this so it is easy for me to sort the filenames. I hope I followed this thread correctly. H
Re: R_X86_64_32S error building a shared library
On Monday 2009-01-26 23:33, Adam Nielsen wrote: $ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared This works since main.cpp is being compiled to main.o with PIC. However, Boost is not involved here so it proves nothing about Boost. It does prove something about Boost to me - as soon as I add the Boost libraries to the above program I get the error, which implies that something isn't compiled with -fPIC. Since Boost was the only thing added, Boost must have been compiled without -fPIC. As previously mentioned, that's just natural for .a libraries :) I think libtool is supposed to record this discrepancy into the .la files it generates, and at the end of the way, when a program is linked against mylib.la, it will finally pull in the boost.a - in the last stage mind ye, when one is about to produce the program, the one spot where non-PIC is ok.
Re: blank line following trailing backslash
On Mon, 26 Jan 2009, Ralf Wildenhues wrote: Jan already provided a way around this. Here's why automake warns about it at all: it is not portable to have a backslash followed by a blank line, as some make implementations are rather unpredictable with it: However, Automake could offer to re-write the list so that the result is portable. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: blank line following trailing backslash
Am Montag, 26. Januar 2009 schrieb Ralf Wildenhues: Hello Andreas, * Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET: fileA.c \ fileB.c \ fileC.c [...] This is not nice so I thought well let's add a backslash after the last file and add an empty line at the end. Then there's no need to modify the fileC line and everybody just adds a line to the list. This can be resolved. But automake doesn't like this at all. Even though it is clearly visible that this is not wrong it complains. It doesn't even warn about this it produces an error. Jan already provided a way around this. Here's why automake warns about it at all: it is not portable to have a backslash followed by a blank line, as some make implementations are rather unpredictable with it: http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin e_002dNewline.html http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin e-Comments.html Hope that helps. Cheers, Ralf Ok, ich verstehe. Ich muß zugeben meine Make und Automake Kenntnisse sind eher gering, aber könnte man nicht eine Warnung ausgeben und den letzten Backslash entfernen? Immerhin erkennt man ihn, es sollte also möglich sein ihn auch weg zu nehmen Andreas
Re: blank line following trailing backslash
* Bob Friesenhahn wrote on Tue, Jan 27, 2009 at 02:47:26AM CET: On Mon, 26 Jan 2009, Ralf Wildenhues wrote: Jan already provided a way around this. Here's why automake warns about it at all: it is not portable to have a backslash followed by a blank line, as some make implementations are rather unpredictable with it: However, Automake could offer to re-write the list so that the result is portable. Yes, it could. Automake however also promises to mostly copy its input to its output literally, and any diversion of that causes friction, bugs and unexpected behavior. Not saying that it couldn't be done safely for this issue. But for the related issue of comment lines ending in backslash it isn't even clear to me which would be the intended result, and not rewriting both would also be inconsistent. Oh well, I'm not strictly against fixing this instance, if somebody provides a good patch (including doc, testsuite updating etc). Cheers, Ralf
