I'm trying to install mimetex on Windows 7. To achieve this, I installed first cygwin on my machine, and then in the prompt window I typed:
gcc -DAA -DWINDOWS mimetex.c gifsave.c -lm -o mimetex.exe
in the right directory.
In the prompt I read:
but the exe was anyway created. When I tried to launch that exe, I saw this error:
Could it be some incompatibility with my Windows version? If yes, how can I solve?
Thanks in advance.
mimetex is using strcasestr that is not C standard and not available in every platform.
Taking the example code from How does strcasestr in C work. Keep getting Error external symbol
and putting in a strcasestr.c file we have
$ cat strcasestr.c
#include <stdlib.h>
#include <ctype.h>
char *strcasestr(const char *str, const char *pattern) {
size_t i;
if (!*pattern)
return (char*)str;
for (; *str; str++) {
if (toupper(*str) == toupper(*pattern)) {
for (i = 1;; i++) {
if (!pattern[i])
return (char*)str;
if (toupper(str[i]) != toupper(pattern[i]))
break;
}
}
}
return NULL;
}
and we can now compile with a lot of warning:
$ x86_64-w64-mingw32-gcc -Wall -DWINDOWS -DAA mimetex.c gifsave.c strcasestr.c -lm -o mimetex.cgi
mimetex.c: In function ‘rastsmash’:
mimetex.c:2384:26: warning: variable ‘ymin’ set but not used [-Wunused-but-set-variable]
....
mimetex.c:16687:2: warning: variable ‘isqempty’ set but not used [-Wunused-but-set-variable]
isqempty = 0, /* true if query string empty */
^~~~~~~~
$ ls -l mimetex.cgi
-rwxr-xr-x 1 Marco Kein 1.8M Jan 1 08:31 mimetex.cgi
Testing it in a CMD session, you can verify as suggested by the README that it is a stand alone windows program:
>mimetex.cgi "x^2+y^2"
+-----------------------------------------------------------------------+
|mimeTeX vers 1.75, Copyright(c) 2002-2017, John Forkosh Associates, Inc|
+-----------------------------------------------------------------------+
| mimeTeX is free software, licensed to you under terms of the GNU/GPL, |
| and comes with absolutely no warranty whatsoever. |
| See http://www.forkosh.com/mimetex.html for details. |
+-----------------------------------------------------------------------+
Most recent revision: 10 June 2017
Ascii dump of bitmap image...
.................***......................................***...
................*...*....................................*...*..
...............**...**..................................**...**.
...............**....*..................................**....*.
....................**...........*...........................**.
....................**...........*...........................**.
....................*............*...........................*..
....**..****.......*.............*...........**.....*.......*...
...*..**...*......*..............*..........*.*.....*......*....
..*...*..........*...*...........*..........*.*.....*.....*...*.
..*...*.........*....*...........*..........*.*.....*....*....*.
.....*.........*******....***************....*.....*....*******.
.....*...........................*...........*.....*............
.....*....*......................*...........*.....*............
.....*....*......................*...........*....**............
*...**...*.......................*...........*...**.............
.***..***........................*............***.*.............
.................................*................*.............
.................................*...............*..............
............................................*...*...............
.............................................***................
Related
I have learnt that, In C, I can read and write to a file when I open a file with "r+" mode.
But the behaviour of my program in different platform is different.
My source code is:
#include <stdio.h>
int main(void)
{
FILE* filePtr = fopen("text.txt", "r+");
char c;
if(filePtr == NULL)
printf("Error on opening file.");
printf("feof = %d\n", feof(filePtr));
while(!feof(filePtr))
{
c = fgetc(filePtr);
fputc('$', filePtr);
}
fclose(filePtr);
return 0;
}
I just want to test the "r+" mode.
The content in "text.txt" is abcdefghijklmnopqrstuvwxyz.
I execute this code in two platform:
Env_0:
Ubuntu 18.04
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
After executing, the content of "text.txt" became "a$c$e$g$i$k$m$o$q$s$u$w$y$.$$" (same as I predicted)
Env_1:
Windows 11 x64
gcc 4.9.2 64-bit (in Dev-cpp 5.11)
The program can not even terminal by itself. and the result is in a mess.
It like `abcdefghijklmnopqrstuvwxyz.$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$... and some garbage character in it.
I try to execute it in different platform.
I have spent a lot of time researching how to compile a simple PostgreSQL test application written in C and I've got it to compile, run and connect to the PostgreSQL database that comes with Mavericks Server om my Mac Mini running OS X 10.9.3.
Then I decided to try using the Xcode IDE to compile and debug the same PostgreSQL code however, in Xcode I am getting references to Postgres methods listing 7 issues related to "Apple Mach-O Linker (ld) Error", including _PQclear, _PQconnectdb, PQerrorMessage, _PQexec, _PQfinish, _PQprint, _PQstatus. The final error is related to Linker command failed with exit code 1 (use -v to see invocation). Note: I'm not sure where to add the -ld parameters in the Xcode IDE or where to put the -v to find out more.
I have read many of the Stack Overflow items but most of them relate to iOS rather than OSX however I tried to figure out how to use many of those suggestions. Unfortunately I still am not able to figure out where to add the ld (LD) item for postgres similar to what I have in my make file. I tried adding and changing different settings on the Build Phases in the Xcode IDE but I keep getting these 8 issues.
In my code that I'm trying to compile from Xcode I changed one line to point to the location where the libpq-fe.h is as follows but I'm not sure if this is the correct or best approach:
#include </Applications/Server.app/Contents/ServerRoot/usr/include/libpq-fe.h>
Here is my makefile that compiles using make pg_test
## File: makefile
## Rules to create libpq sample application
LDLIBS += -L/Applications/Server.app/Contents/ServerRoot/usr/lib/postgresql9.1/ -lpq
CFLAGS += -c -v -g -I/Applications/Server.app/Contents/ServerRoot/usr/include/
LDFLAGS += -g
pg_test: pg_test.o
Here is my pg_test.c code
// File: pg_test.c
#include <stdlib.h>
#include <libpq-fe.h>
void process_query (PGconn * connection, const char * query_text ) {
PGresult * result;
PQprintOpt options = {0};
if(( result = PQexec ( connection, query_text )) == NULL ) {
printf( "%s\n", PQerrorMessage ( connection ));
return;
}
options.header = 1;
options.align = 1;
options.fieldSep = "|";
PQprint (stdout, result, &options );
PQclear ( result );
}
int main ( ) {
PGconn * connection;
char * dbarg = "user=jerry password=test dbname=jletter hostaddr=127.0.0.1 port=5432";
connection = PQconnectdb(dbarg);
if( PQstatus( connection ) != CONNECTION_OK )
printf( "%s\n", PQerrorMessage( connection ));
else {
process_query( connection, "SELECT * FROM friends" );
}
PQfinish ( connection );
exit (0);
}
Any help would be greatly appreciated.
I'm trying to run the following simple example from Xcode4:
#include <boost/mpi/environment.hpp>
#include <boost/mpi/communicator.hpp>
#include <iostream>
namespace mpi = boost::mpi;
int main(int argc, char* argv[])
{
mpi::environment env(argc, argv);
mpi::communicator world;
std::cout << "I am process " << world.rank() << " of " << world.size()
<< "." << std::endl;
return 0;
}
I've added libboost_mpi and libboost_serialization to Xcode, and compiling using the default LLVM returns :
/usr/local/include/boost/mpi/communicator.hpp:1329:9: error: call to
implicitly-deleted copy constructor of 'boost::mpi::communicator'
: comm(comm), source(source), tag(tag), ia(comm), value(value)
^ ~~~~
However, I can compile and run using
mpic++ -I/usr/local/include main.cpp -L/usr/local/lib
-lboost_mpi -lboost_serialization
Although mpic++ seems to be calling through to LLVM:
$ mpic++
i686-apple-darwin11-llvm-g++-4.2: no input files
Anyways, I tried adding mpic++ as a compiler option in Xcode 4. I can run
$ sudo opensnoop -n Xcode | grep mpicc.xcspec
and see that the spec file is being loaded by Xcode, but I don't see any MPICC option. My spec file is fairly simple:
/**
Xcode Compiler Specification for MPICC
*/
{ Type = Compiler;
Identifier = com.apple.compilers.mpicc;
BasedOn = com.apple.compilers.gcc.4_2;
Name = “MPICC”;
Version = “Default”;
Description = “MPI GNU C/C++ Compiler 4.0″;
ExecPath = “/usr/local/bin/mpicc”;
PrecompStyle = pch;
}
and it's stored in
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/LLVM GCC 4.2.xcplugin/Contents/Resources/mpicc.xcspec
So this works:
link binary with:
libmpi_cxx.dylib
libmpi.dylib
libboost_mpi.dylib
libboost_serialization.dylib
Change compiler (under build options) to LLVM GCC 4.2 (hinted at by running mpic++ directly, which reports that it's using llvm gcc 4.2 internally)
Under targets, build phases, compile sources, add the compiler option "-lm" to report that you need to link with libm. Credit to #pyCthon for pointing out mpic++ --showme:link which revealed the final library that was allowing it to build successfully from the command line
When compiling some working code on Fedora 11, I am getting this error:
/usr/include/c++/4.4.1/cstdarg:56: error: ‘::va_list’ has not been declared
I am using:
[doriad#davedesktop VTK]$ g++ --version
g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Does anyone know what the problem could be?
I had the same error message and I solved including one of the next files
#include <stdarg.h>
or
#include <cstdarg>
Bringing in the varadic macro set in g++ 4.4 has confusing and twisted semantics. You might get a better idea of what isn't happening by using g++ -E broken_code.cpp and looking at what the pre-processor is bringing in. There are a few dozen GNU C preprocessor directives that could prevent the ::va_list declaration from compiling as __gnuc_va_list which itself is of type __builtin_va_list
The junk code:
$cat junk.cpp
#include <cstdarg>
void foo(char *f, ...) { va_list va; va_start(va, va); }
int main(void) { foo("", "", ""); return 0; }
$ g++ junk.cpp
$ g++ --version
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
compiles and links (with warnings) with the relevant output of g++ -E junk.cpp being:
# 40 "/usr/lib/gcc/i486-linux-gnu/4.4.1/include/stdarg.h" 3 4
typedef __builtin_va_list __gnuc_va_list;
# 102 "/usr/lib/gcc/i486-linux-gnu/4.4.1/include/stdarg.h" 3 4
typedef __gnuc_va_list va_list;
# 45 "/usr/include/c++/4.4/cstdarg" 2 3
# 54 "/usr/include/c++/4.4/cstdarg" 3
namespace std __attribute__ ((__visibility__ ("default"))) {
using ::va_list;
}
I encountered "SYS#0" at the top of a stack and cannot find any documentation as to what that means.
Compiler: g++
OS: Solaris 9
Arch: SPARC
Memory Manager libhoard_32.so from Hoard 3.5.1
We used "gcore" to generate a core file. Looking at the output of running the "pstack" command against the core file, the only thread that was doing anything interesting had the following at the very top of its call stack:
ff309858 SYS#0 ()
ff309848 void MyHashMap<const void*,unsigned,AlignedMmapInstance<65536U>::SourceHeap>::set(const void*,unsigned) (ff31eed4, 9bf20000, 10000, 40, 9bf1fff0, ff31e738) + 134
...
pflags for that LWP shows:
/8: flags = PR_STOPPED|PR_ISTOP|PR_ASLEEP
why = PR_REQUESTED
sigmask = 0xfffffeff,0x00003fff
I could not find any mention of this syntax in the Sun documentation.
Edit: The process appears to have hung sometime prior to doing the gcore. Is "SYS#0" somehow interrelated with process hangs?
Edit: Added next stack frame and link to Hoard, pflags output
Edit: The accepted answer is correct. In addition, at least on SPARC, the g1 register should contain the system call number, but this did not appear to be the case in our core file.
The topic "what is an indirect system call?" is probably good material for another question.
Try this:
$ cat foo.c
#include <stdio.h>
int main(int argc, char *argv[]) {
char buf[1024];
proc_sysname(0, buf, 1024);
printf("%s\n", buf);
}
$ gcc -ofoo -lproc foo.c
$ ./foo
SYS#0
$
SYS#0 is therefore the string that represents system call zero. If you look in <sys/syscall.h> (the system call table) you will find the following:
/* syscall enumeration MUST begin with 1 */
/*
* SunOS/SPARC uses 0 for the indirect system call SYS_syscall
* but this doesn't count because it is just another way
* to specify the real system call number.
*/
#define SYS_syscall 0
The indirect system call syscall(SYS_syscall, foo, bar, ...) is equivalent to the direct call syscall(foo, bar, ...).