amtssk#DEVICE PERT % make
/usr/local/bin/gfortran-11 -fno-backslash -Wall -Wno-tabs -O -m64 -o pert objects/main.o objects/start.o objects/metric.o objects/march.o objects/mar1d.o objects/usrpq.o objects/bound.o objects/flux.o objects/plot.o objects/rwmodel.o objects/utilities.o objects/vsr.o objects/usr.o objects/myio.o -L /Users/amtssk/OneDrive - University of Leeds/oldmac/Computing/Serial/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11
gfortran-11: error: -E or -x required when input is from standard input
make: *** [pert] Error 1
I have found the reason - the very unfortunate name for the corporate OneDrive folder, OneDrive - University of Leeds. It was quoted in the relevant path variable but became unquoted when passed to the compiler. Thank you Albert, I have just noticed you pinpointing this too!
Related
I am trying to make a shared library for a particular problem I was working on. It has "point_sense.c" as the main file which uses functions defined in "createPolygon.c." The functions are declared in a header file "createPolygon.h."
To compile them, I used a makefile which looks like the following
all:point_sense
createPolygon.o:createPolygon.c
g++ -c -fpic createPolygon.c
libcreatePolygon.so:createPolygon.o
g++ -shared -o libcreatePolygon.so createPolygon.o
point_sense:point_sense.c libcreatePolygon.so
g++ -o point_sense -L~Desktop/Summer_2020_linux/tutorials/cpp_practise point_sense.c -lcreatePolygon
clean:
rm point_sense createPolygon.o libcreatePolygon.so
but when I make the file, it gives an output as
g++ -c -fpic createPolygon.c
g++ -shared -o libcreatePolygon.so createPolygon.o
g++ -o point_sense -L~Desktop/Summer_2020_linux/tutorials/cpp_practise point_sense.c -lcreatePolygon
/usr/bin/ld: cannot find -lcreatePolygon
collect2: error: ld returned 1 exit status
make: *** [makefile:10: point_sense] Error 1
Initially I thought this was some silly mistake, and to check I used
ld -L~/Desktop/Summer_2020_linux/tutorials/cpp_practise -lcreatePolygon -verbose
and after a long output I got (a few unimportant lines in the code are skipped in between)
ld: mode elf_x86_64
attempt to open ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.so failed
attempt to open ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.a failed
attempt to open /usr/local/lib/x86_64-linux-gnu/libcreatePolygon.so failed
attempt to open /usr/local/lib/x86_64-linux-gnu/libcreatePolygon.a failed
.
.
.
ld: cannot find -lcreatePolygon
But when I try to open 'libcreatePolygon.so' directly, I am able to open it.
$ nano ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.so
There are several threads which explain the process of doing this, but I don't see what it is that I am doing wrong. Any help is appreciated.
I am using Ubuntu 20.04.1 LTS and g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0 .
I tried to reproduce the problem here, and this error message goes away if you put a space between the -L flag and the tilde character.
The reason is: if there is no space between -L and ~, the tilde character cannot be expanded to the home directory.
I'm trying to compile w3m for Windows XP using MinGW or TDM-GCC. After applying the patch at W3m patch - Linux from scratch and adding -lws2_32 to LIBS at Makefile I have come across these 5 Windows-incompatible functions (in the order of first appearance)
bcopy (at Str.c)
sleep (at file.c)
kill (at image.c)
open_pipe_rw (at image.c)
fork (at image.c)
I have fixed the first two by defining their Windows equivalents like:
void bcopy(const void *from, void *to, size_t n) {
int *dummy;
dummy = memcpy(to, from, n);
}
#define sleep(n) Sleep(n*1000)
After these, all object files were compiled fine but those three Unix functions being called from image.o prevented w3m.exe from being formed at the linking stage:
$ make
(cd libwc && make CC='gcc' OPTS='')
make[1]: Entering directory '/c/Documents and Settings/ibm/Downloads/w3m-0.5.3/libwc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/Documents and Settings/ibm/Downloads/w3m-0.5.3/libwc'
gcc -I. -I. -g -O2 -I./libwc -IC:/msys32/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\"/usr/local/libexec/w3m\"
-DCGIBIN_DIR=\"/usr/local/libexec/w3m/cgi-bin\" -DHELP_DIR=\"/usr/local/share/w3m\" -DETC_DIR=\"/usr/local/etc\" -DCONF_DIR=\"/usr/local/etc/w3m\"
-DRC_DIR=\"~/.w3m\" -DLOCALEDIR=\"/usr/local/share/locale\"
-o w3m.exe main.o file.o buffer.o display.o etc.o search.o linein.o
table.o local.o form.o map.o frame.o rc.o menu.o mailcap.o image.o
symbol.o entity.o terms.o url.o ftp.o mimehead.o regex.o news.o func.o
cookie.o history.o backend.o keybind.o anchor.o parsetagx.o tagtable.o
istream.o version.o -lws2_32 -lpthread -L. -lindep -lgc -L./libwc -lwc
-LC:/msys32/usr/local/lib -lssl -lcrypto -lssl -lcrypto -lncurses
./libindep.a(indep.o): In function `bcopy':
C:\Documents and Settings\ibm\Downloads\w3m-0.5.3/indep.c:74: multiple definition of `bcopy'
./libindep.a(Str.o):C:\Documents and Settings\ibm\Downloads\w3m-0.5.3/Str.c:36: first defined here image.o: In function `closeImgdisplay':
C:\truncated\w3m-0.5.3/image.c:126: undefined reference to `kill'
image.o: In function `openImgdisplay':
C:\truncated\w3m-0.5.3/image.c:93: undefined reference to `open_pipe_rw'
image.o: In function `loadImage':
C:\truncated\w3m-0.5.3/image.c:354: undefined reference to `kill'
C:\truncated\w3m-0.5.3/image.c:383: undefined reference to `kill'
C:\truncated\w3m-0.5.3/image.c:436: undefined reference to `fork'
collect2.exe: error: ld returned 1 exit status
Makefile:130: recipe for target 'w3m.exe' failed
make: *** [w3m.exe] Error 1
How can I define the Windows equivalents of those three Unix functions? If you can suggest any other solution like giving specific options to or editing the configure command and/or Makefile so that the image.c uses the Windows equivalents of those functions, that's fine too. Thanks.
Build the program for Cygwin; then turn it into a native application with Cygnal by bundling it together with the Cygwin DLL's it needs, but with cygwin1.dll from Cygnal instead of Cygwin.
Cygwin has fork, kill and numerous other POSIX functions.
Also, Cygwin provides bi-directional ANSI/VT100 emulation, right over the Windows Console API. This means that programs that interact with terminals using raw escape sequences will workâright out of the cmd.exe console window. The POSIX termios function work nicely for setting up character-at-a-time input and all that.
I'm trying to compile GNU Source highlight in my home directory.
I configured with a prefix and --with-boost=/path/to/boost/root/dir/ and no errors were reported.
But when I try to build I got the following error:
$ make
... # lots of output
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginS.o .libs/copyright.o .libs/reportbugs.o .libs/fileutil.o .libs/substfun.o .libs/stopwatch.o .libs/utils.o .libs/ioexception.o .libs/settings.o .libs/versions.o .libs/verbosity.o .libs/sourcehighlight.o .libs/styleparser.o .libs/stylescanner.o .libs/outlangdefparser.o .libs/stylecssparser.o .libs/stylecssscanner.o .libs/outlangdefscanner.o .libs/debuglistener.o .libs/langmap.o .libs/stylefileparser.o .libs/langelem.o .libs/statelangelem.o .libs/langelems.o .libs/statestartlangelem.o .libs/stringlistlangelem.o .libs/delimitedlangelem.o .libs/langelemsprinter.o .libs/namedsubexpslangelem.o .libs/stringdef.o .libs/highlightrule.o .libs/highlighttoken.o .libs/highlightstate.o .libs/highlightrulefactory.o .libs/highlightstateprinter.o .libs/sourcehighlighter.o .libs/sourcefilehighlighter.o .libs/linenumgenerator.o .libs/lineranges.o .libs/regexranges.o .libs/formatter.o .libs/formattermanager.o .libs/textstyle.o .libs/textstyleformatter.o .libs/bufferedoutput.o .libs/preformatter.o .libs/wordtokenizer.o .libs/ctagscollector.o .libs/readtags.o .libs/ctagsformatter.o .libs/srcuntabifier.o .libs/textstyleformatterfactory.o .libs/docgenerator.o .libs/doctemplate.o .libs/chartranslator.o .libs/textstylebuilder.o .libs/fileinfo.o .libs/ctagsmanager.o .libs/regexhighlightrule.o .libs/regexrulefactory.o .libs/regexpreprocessor.o .libs/highlightstatebuilder.o .libs/highlightbuilderexception.o .libs/langdefmanager.o .libs/langdefparser.o .libs/langdefscanner.o .libs/languageinfer.o .libs/parserexception.o .libs/stringtable.o .libs/vardefinitions.o .libs/sourcehighlightutils.o .libs/yywrap.o -Wl,--whole-archive ../../gl/.libs/libgnu.a -Wl,--no-whole-archive -lboost_regex -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o -Wl,-soname -Wl,libsource-highlight.so.1 -o .libs/libsource-highlight.so.1.1.0
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
Note that, I have Boost loaded in my environment, in fact:
$ echo $LD_LIBRARY_PATH
/path/to/boost/root/dir/lib:/other/path/lib
and ls shows that /path/to/boost/root/dir/lib/libboost_regex.so exists and is a symbolic link to libboost_regex.so.1.47.0
How is this possible? How can I solve it?
At linking time, the correct environment variable to use to define the path where to find the libraries is LIBRARY_PATH, not LD_LIBRARY_PATH. The former is equivalent to specifying -L in the gcc arguments, while the latter is used at runtime, like PATH, to find the binary executables. See this for more information.
I'm having trouble building a project that attempts to check for the presence of shm_open and shm_unlink. The relevant lines of configure.ac are:
# Avoid adding rt if absent or unneeded
AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"])
# needs -lrt on linux
AC_CHECK_FUNCS([shm_open shm_unlink])
The AC_CHECK_LIB line succeeds, however AC_CHECK_FUNCS fails for both. Looking in config.log, I see
configure:4133: checking for shm_open in -lrt
configure:4158: /usr/bin/gcc -o conftest -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c -lrt >&5
configure:4158: $? = 0
configure:4167: result: yes
configure:4178: checking for shm_open
configure:4178: /usr/bin/gcc -o conftest -fno-stack-protector -lrt -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c >&5
/tmp/ccg0yu56.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `shm_open'
collect2: ld returned 1 exit status
It appears that the only difference between the two checks is the position of the -lrt argument. When I try running gcc on a simple file manually, I get the same behavior, i.e. linking succeeds only when -lrt comes after the source file input.
So, what do I need to do so configure will determine that shm_open and shm_unlink exist? I suspect this is something particular to my system, as the project I'm configuring is pretty widely used (the unix package bundled with the ghc compiler), and it used to work (when I built this package on a different system with gcc-4.4.5, it worked, however that environment is no longer available). My preferred solution would be either a change to the system/environment or some combination of flags to configure, however if there's a standard modification for configure.ac that I could send upstream, that's acceptable also.
I've tried various combinations of CFLAGS and LDFLAGS, but the -lrt flag always appears before the input file, so the check still fails.
My system is Ubuntu 12.04 (precise)
$gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
$ uname -a
Linux hostname 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Thanks!
Macro have full form:
AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])
Please note other-libraries. This option is useful specifically for cases you described -- to pass -lm, -lrt and other common guys to avoid unresolved references in linker ordering.
Check doc page for more information on AC_CHECK_LIB macro
Hadoop n00b here, just started playing around with Hadoop Pipes. I'm getting linker errors while compiling a simple WordCount example using hadoop-0.20.203 (current most recent version) that did not appear for the same code in hadoop-0.20.2
Linker errors of the form: undefined reference to `EVP_sha1' in HadoopPipes.cc.
EVP_sha1 (and all of the undefined references I get) are part of the openssl library which HadoopPipes.cc from hadoop-0.20.203 uses, but hadoop-0.20.2 does not.
I've tried adjusting my makefile to link to the ssl libraries, but I'm still out of luck. Any ideas would be greatly appreciated. Thanks!
PS, here is my current makefile:
CC = g++
HADOOP_INSTALL = /usr/local/hadoop-0.20.203.0
SSL_INSTALL = /usr/local/ssl
PLATFORM = Linux-amd64-64
CPPFLAGS = -m64 -I$(HADOOP_INSTALL)/c++/$(PLATFORM)/include -I$(SSL_INSTALL)/include
WordCount: WordCount.cc
$(CC) $(CPPFLAGS) $< -Wall -Wextra -L$(SSL_INSTALL)/lib -lssl -lcrypto -L$(HADOOP_INSTALL)/c++/$(PLATFORM)/lib -lhadooppipes -lhadooputils -lpthread -g -O2 -o $#
The actual program I'm using can be found at http://cs.smith.edu/dftwiki/index.php/Hadoop_Tutorial_2.2_--_Running_C%2B%2B_Programs_on_Hadoop
Had same problem here: answer is to add -lcrypto to the compile command line:
http://grokbase.com/p/hadoop.apache.org/common-user/2011/06/re-linker-errors-with-hadoop-pipes/09zqdt5grdudu7no7q6k3gfcynpy
Here is a patch to fix the build process:
diff --git src/examples/pipes/Makefile.in src/examples/pipes/Makefile.in
index 17efa2a..1d8af8e 100644
--- src/examples/pipes/Makefile.in
+++ src/examples/pipes/Makefile.in
## -233,7 +233,7 ## AM_CXXFLAGS = -Wall -I$(HADOOP_UTILS_PREFIX)/include \
-I$(HADOOP_PIPES_PREFIX)/include
LDADD = -L$(HADOOP_UTILS_PREFIX)/lib -L$(HADOOP_PIPES_PREFIX)/lib \
- -lhadooppipes -lhadooputils
+ -lhadooppipes -lhadooputils -lcrypto
# Define the sources for each program
You just need to make some changes to your Makefile. The libraries that natively accompany hadoop seem not to do it. You'll need to "re-make" them and change your linked path.
A comprehensive answer to this can be found at http://goo.gl/y5iGZF.