getting memory mapped IO to work on linux

[Peter Nolan]

Hi All,
I am on g++ 3.2.2 and red hat linux on x86..not sure which version....I
have a software product that I wrote that works on win/solaris/aix and
now we are trying to compile it on linux for the first time.

We are getting a message saying synch.h is not found on the linux
machine. When we search the machine it is not there.

I've talked to the sys admins for the machine and they tell me they are
unsure which part of the gnu g++ package they should install to be able
to do this sort of coding on linux. They tell me if I can find out what
portion of g++ they should install they can install it for me.

I am no expert on the g++ compiler or linux so I am not sure how to
explain to the sysadmins what exactly they need to do to get the
support I need to be able to compile on linux.

On solaris/aix synch.h is required to define semaphores I believe.

Any guidance would be most gratefully accepted.

Best Regards

Peter Nolan
www.peternolan.com

We have a header at the start of the program as follows:
#include <synch.h>
#include <sys/mman.h>

I then define my semaphors as follows:

/* shared variables */

sema_t *mutex; /* mutex: semaphore for mutual exclusion
*/

sema_t *full; /* full: semaphore for process
synchronisation */
/* it denotes the number of full
slots */

sema_t *empty; /* empty: semaphore for process
synchronisation */
/* it denotes the number of empty
slots */

I then create them like follows:

if ((mutex_fp = creat("/tmp/mutex", PERMISSIONS)) == -1) {
printf("Fatal error: cannot create mutex semaphore file\n");
exit(0);
}
else {
write(mutex_fp, dummy_int, 4);
close(mutex_fp);
}

Open them like follows:
if ((mutex_fp = open("/tmp/mutex", O_RDWR, 0)) == -1) {
printf("Fatal error: cannot open mutex semaphore file\n");
exit(0);
}

Memory map them as follows:

if ((mutex = (sema_t *) mmap((caddr_t) 0, 4, (PROT_READ|PROT_WRITE),
MAP_SHARED, mutex_fp, 0)) == MAP_FAILED) {
mmap_error(errno);
}

All I can find that is similar in the linux g++ is semaphore.h that
contains code like the following...

On linux should I be using these calls rather than sema_init etc?

__BEGIN_DECLS

/* Initialize semaphore object SEM to VALUE. If PSHARED then share it
with other processes. */
extern int sem_init (sem_t *__sem, int __pshared, unsigned int __value)
__THROW;

/* Free resources associated with semaphore object SEM. */
extern int sem_destroy (sem_t *__sem) __THROW;

/* Open a named semaphore NAME with open flaot OFLAG. */
extern sem_t *sem_open (__const char *__name, int __oflag, ...)
__THROW;

/* Close descriptor for named semaphore SEM. */
extern int sem_close (sem_t *__sem) __THROW;

/* Remove named semaphore NAME. */
extern int sem_unlink (__const char *__name) __THROW;

/* Wait for SEM being posted. */
extern int sem_wait (sem_t *__sem);

#ifdef __USE_XOPEN2K
/* Similar to `sem_wait' but wait only until ABSTIME. */
extern int sem_timedwait (sem_t *__restrict __sem,
__const struct timespec *__restrict __abstime);
#endif

/* Test whether SEM is posted. */
extern int sem_trywait (sem_t *__sem) __THROW;

/* Post SEM. */
extern int sem_post (sem_t *__sem) __THROW;

/* Get current value of SEM and store it in *SVAL. */
extern int sem_getvalue (sem_t *__restrict __sem, int *__restrict
__sval)
__THROW;

__END_DECLS

[Paul Pluzhnikov]

"Peter Nolan" <pe...@peternolan.com> writes:

> We are getting a message saying synch.h is not found on the linux
> machine. When we search the machine it is not there.

It appears that you are using non-portable sema_... interfaces.
Any reason not to use the POSIX interfaces instead?

"Solaris to Linux" porting guide:
http://h21007.www2.hp.com/dspp/files/unprotected/linux/sol_to_linux_porting_guide.pdf
says that sema_post() maps directly into (POSIX-standard) sem_post().

> I've talked to the sys admins for the machine and they tell me they are
> unsure which part of the gnu g++ package they should install to be able
> to do this sort of coding on linux.

There is unlikely exist any part of g++ package which will help
you here: use non-portable interfaces at your own peril.

> On linux should I be using these calls rather than sema_init etc?

You should probably use them everywhere; not just on Linux.
That will make your software portable.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Peter Nolan]

Hi Paul,
thanks very much for the pointer........I am not a 'day to day'
unix/linux developer which is why I didn't know sema_post was specific
to unix.....I was given some example memory mapped IO code that worked
on solaris and based my memory mapped pieces of code on that....it
worked ok on solaris/aix and this is my first try on linux.

It looks like the type should also be sem_t rather than sema_t on
linux.

I might be asking for too much advice so please feel free not to
answer....but when people write code to be portable to linux as well as
unix do they need to put in a compiler directive to compile/not compile
specific code like is necessary for windows/unix portable software?

Thanks very much....I really appreciate the pointer to the porting
guide....

Peter
www.peternolan.com

[S7Solutions]

Hello there,

Usually there are so many things that are used are very specific to a
given OS or to a given compiler and we have always used these
directives like

#ifdef linux_i32

or #ifdef sol2

or for compiler for say HP aCC

#ifdef HP_ACC etc

These are just place holders but you get all those defines listed out
from the compiler when you run the compiler with a -A or a -V I guess.
Hey I am a sales guy @ S7 - so I woudn't know all teh details :-) but
if you are serious I can put some techies in touch with you and they
will tell you how to do this all as they have I guess ported few 100s
of millions of code from unix to Linux and windows to unix/Linux!!!

Manju

*** CUSTOMER comes FIRST, come what may ********

Manjunath M
S7 Software Solutions Pvt. Ltd.
#83 Railway Parallel Road, Kumara Park West
Bangalore - 560020, India
Telephone: +91-80-51526777
Fax: +91-80-2334135

2936 173rd CT NE
Redmond, WA 98052, USA
Telephone: (425) 867 1457
Fax: (425) 883 2597
Toll Free: 1-888-224-6174

Yahoo messenger ID: s7softwaresolutions
MSN messenger ID: manj...@hotmail.com
Skype ID: s7softwaresolutions

http://www.s7solutions.com

"Redefining cross-platform porting & migration"

************************************************

[Peter Nolan]

Hi Manju,
well, I guess the truth is that my clients are not 'serious' about
unix/linux because all the ones who have paid so far are on windows.
Serious = pay for my software.. ;-)

I used my software on solaris/aix and now release/support it on those
OSs but no-one has given me money for them yet!

A few prospects asked and I refused to try it out on linux because
companies who don't want to pay for a zillions lines of OS software are
not likely to pay for my software.....however, my current client has a
linux development machine so we are trying to get it to run on
linux....but they are not paying for the software. I am going to use my
software because it makes my life less tedious and saves the client
lots of time and effort. It's just that their oracle development
licenses are all on linux and they have no win servers or oracle
licenses we can use.....

When some clients actually want to pay for unix/linux versions perhaps
I'll hire some real unix/linux programmers to make sure it is the best
it can be..;-)

Thanks for the offer

Peter.

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> thanks very much for the pointer........I am not a 'day to day'
> unix/linux developer which is why I didn't know sema_post was specific

Which may explain why some of your conncepts are a little off.

> I might be asking for too much advice so please feel free not to
> answer....but when people write code to be portable to linux as well as
> unix

No no, you are writing to be portable _across_ unix! You have been
using constructs that are pariticular to a particular unix o/s or subset
of unix o/s's and you need to use more portable constructs (though I
don't know if your library is available or not on linux, *bsd etc.).

Peter

[Peter Nolan]

Hi Peter,
well, I only ever intended to be portable across windows/solaris. I
added AIX because I was working on an AIX client.......so having a
problem with is linux is normal...

In the end, my software clients will be win when the system is small
and solaris when it is large. They can have any flavour unix they like,
as long as it is solaris. The other flavour of unix they can have is
windows...;-)

That my client cannot provide a single person anywhere on the planet
who can compile the hello world program on any of their linux servers
is nothing short of amazing for me.....

How do people call themselves IT people when they cannot compile the
worlds simplest programs on their chosen OS? "Yes, I'm an IT expert but
I don't know how to compile the worlds simplest program on the OS I
support."

A sad reflection on our industry would be my comment.

I think we will spend more money (time) getting this software compiled
on linux than a new win server would cost us!! (but not a new oracle
license of course...)

Peter
www.peternolan.com

[Peter Nolan]

Hi All,
well, I have made progress and gotten rid of my thread compiling
problem by changing the code to posix compliant threads....

However the next problem comes up....

For some reason the link editor cannot find all the istream/ostream
links time libraries???

I searched all over the machine to find libstdc++ and found it in
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 and that seemed to get rid of
the error for cout but it did not get rid of the error for ostream etc.

find / -name "libg++.a" -print 2>/dev/null returns no results...should
I have a libg++.a or .so?

I have tried all varieties of iostream.h and iostream etc...I have
tried all variants of using namespace std...

I have tried nm -po
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/libstdc++.a | c++filt | grep
ostream and there seems to be ostream functions in there....

I have searched all over these newsgroups and they say include stdc++
or stdcxx and I have been searching all over the machine for these
things and included ones that looked like they might be the correct
ones with no success.

The admins for the machines do not do any compiling of software and are
on thanksgiving holidays anyway.

Would anyone out there be able to assist? All assistance most
gratefully appreciated.

Peter Nolan
www.peternolan.com

The command I am using to compile is as follows.

g++ -o CDWU001 -DODBCVER=0x0352 -Dunix -Dlinux -g
-I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
CDWU001.cpp -L/usr/local/easysoft/unixODBC/lib
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread
-lstdc++-3-libc6.2-2-2.10.0 -lstdc++ -lc -lm

istream and ostream variants are as follows:

//#include <iostream.h>
//#include <fstream.h>

#include <iostream>
#include <fstream>
using namespace std ;
//using namespace std ;

Statements that fail are as follows:

DEBUG_PRINT(RU015_TranslateDateTimeFormat) ;
DEBUG_VARIABLE(DatabaseType) ;
DEBUG_VARIABLE(DateFormatFromInd) ;
DEBUG_VARIABLE(DateDelimiterInd) ;
DEBUG_VARIABLE(date_to_edit) ;

#define DEBUG_VARIABLE(p) if (ws_debug_level > 0) cout << #p << "=" <<
p << '\n'
#define DEBUG_PRINT(p) if (ws_debug_level > 0) cout << #p << '\n'

Error messages are as follows:

/tmp/ccAQ4Bcf.o(.text+0xb11): In function
`RU014_TranslateDateFormat(int, int, int, char*)':
/home/pnolan/idw/include/dwfunctions.h:753: undefined reference to
`ostream::operator<<(char const*)'
/tmp/ccAQ4Bcf.o(.text+0xb1a):/home/pnolan/idw/include/dwfunctions.h:753:
undefined reference to `ostream::operator<<(char)'
/tmp/ccAQ4Bcf.o(.text+0xb48):/home/pnolan/idw/include/dwfunctions.h:754:
undefined reference to `ostream::operator<<(char const*)'
/tmp/ccAQ4Bcf.o(.text+0xb51):/home/pnolan/idw/include/dwfunctions.h:754:
undefined reference to `ostream::operator<<(char const*)'
/tmp/ccAQ4Bcf.o(.text+0xb5a):/home/pnolan/idw/include/dwfunctions.h:754:
undefined reference to `ostream::operator<<(int)'
/tmp/ccAQ4Bcf.o(.text+0xb63):/home/pnolan/idw/include/dwfunctions.h:754:
undefined reference to `ostream::operator<<(char)'
/tmp/ccAQ4Bcf.o(.text+0xb91):/home/pnolan/idw/include/dwfunctions.h:755:
undefined reference to `ostream::operator<<(char const*)'
/tmp/ccAQ4Bcf.o(.text+0xb9a):/home/pnolan/idw/include/dwfunctions.h:755:
undefined reference to `ostream::operator<<(char const*)'

/home/pnolan/idw/include/CFILEAccess.h:209: undefined reference to
`ifstream::open(char const*, int, int)'
/tmp/ccAQ4Bcf.o(.text+0xa166):/home/pnolan/idw/include/CFILEAccess.h:210:
undefined reference to `ios::fail() const'
/tmp/ccAQ4Bcf.o(.text+0xa183):/home/pnolan/idw/include/CFILEAccess.h:210:
undefined reference to `ios::bad() const'
/tmp/ccAQ4Bcf.o(.text+0xa1d4):/home/pnolan/idw/include/CFILEAccess.h:224:
undefined reference to `ofstream::open(char const*, int, int)'
/tmp/ccAQ4Bcf.o(.text+0xa1fb):/home/pnolan/idw/include/CFILEAccess.h:225:
undefined reference to `ios::fail() const'
/tmp/ccAQ4Bcf.o(.text+0xa226):/home/pnolan/idw/include/CFILEAccess.h:225:
undefined reference to `ios::bad() const'
/tmp/ccAQ4Bcf.o(.text+0xa287): In function
`CFILERecordset::ReadNext()':
/home/pnolan/idw/include/CFILEAccess.h:253: undefined reference to
`istream::getline(char*, int, char)'
/tmp/ccAQ4Bcf.o(.text+0xa2ba):/home/pnolan/idw/include/CFILEAccess.h:259:
undefined reference to `ios::eof() const'
/tmp/ccAQ4Bcf.o(.text+0xa7ed): In function
`CFILERecordset::WriteRow(table_field_desc_array_struct*)':
/home/pnolan/idw/include/CFILEAccess.h:466: undefined reference to
`ostream::write(char const*, int)'
/tmp/ccAQ4Bcf.o(.text+0xaad1): In function
`CFILERecordset::WriteRow()':

[Peter Nolan]

PS. when I search for libstdc++.so I get the following...we are using
3.2.2. so I tried the libstdc++.so in that directory.

[pnolan@nodsdvdb2 idw]$ find / -name "libstdc++.so" -print 2>/dev/null
/opt/oracle/product.9204/Agent/lib/stubs/libstdc++.so
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/libstdc++.so
/usr/lib/gcc-lib/i386-redhat-linux7/2.96/libstdc++.so
/usr/lib/gcc-lib/i386-redhat-linux7/2.96/wchar-stdc++/libstdc++.so
[pnolan@nodsdvdb2 idw]$

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> well, I only ever intended to be portable across windows/solaris. I

You need to use POSIX as your target platform. Then everyone will be
happy. Windows, solaris, *bsd, linux, aix, whatever - all support
posix.

Peter

[Peter Nolan]

If it helps....I also did hello world as follows...

Any pointers to where I should be looking for these library files most
appreciated...:-)

Thanks

Peter

#include <iostream>

int main()
{
cout << "Hello, world!" << endl;
return 0;
}

[pnolan@nodsdvdb2 idw]$ g++ -o hello -DODBCVER=0x0352 -Dunix -g
-I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
hello.cpp -L/usr/local/easysoft/unixODBC/lib

-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread
-lstdc++-3-libc6.2-2-2.10.0 -lstdc++ -lc -lm

/tmp/ccKnfZfK.o(.text+0x14): In function `main':
/home/pnolan/idw/hello.cpp:6: undefined reference to `endl(ostream&)'
/tmp/ccKnfZfK.o(.text+0x26):/home/pnolan/idw/hello.cpp:6: undefined

reference to `ostream::operator<<(char const*)'

/tmp/ccKnfZfK.o(.text+0x2f):/home/pnolan/idw/hello.cpp:6: undefined
reference to `ostream::operator<<(ostream& (*)(ostream&))'
collect2: ld returned 1 exit status

[Peter Nolan]

if it helps...I used -v to show what the compiler is doing...

sorry for multiple appends..

Peter

[pnolan@nodsdvdb2 idw]$ g++ -o hello -DODBCVER=0x0352 -Dunix -g
-I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
hello.cpp -L/usr/local/easysoft/unixODBC/lib
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread

-lstdc++-3-libc6.2-2-2.10.0 -lstdc++ -lc -lm -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cc1plus -v
-I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
-D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2
-D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux
-D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__
-DODBCVER=0x0352 -Dunix hello.cpp -D__GNUG__=3 -D__DEPRECATED
-D__EXCEPTIONS -quiet -dumpbase hello.cpp -g -version -o
/tmp/ccWE0gSF.s
GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
(i386-redhat-linux)
compiled by GNU C version 3.2.2 20030222 (Red Hat Linux
3.2.2-5).
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/home/pnolan/idw/include
/usr/include/g++-3
/usr/include/c++/3.2.2
/usr/include/c++/3.2.2/i386-redhat-linux
/usr/include/c++/3.2.2/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include
/usr/include
End of search list.
as -V -Qy -o /tmp/ccInuSdg.o /tmp/ccWE0gSF.s
GNU assembler version 2.14.90.0.4 (i386-redhat-linux) using BFD version
2.14.90.0.4 20030523
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtbegin.o
-L/usr/local/easysoft/unixODBC/lib
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../.. /tmp/ccInuSdg.o
-lodbc -lpthread -lstdc++-3-libc6.2-2-2.10.0 -lstdc++ -lstdc++ -lm -lc
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtend.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crtn.o
/tmp/ccInuSdg.o(.text+0x14): In function `main':
/home/pnolan/idw/hello.cpp:8: undefined reference to `endl(ostream&)'
/tmp/ccInuSdg.o(.text+0x26):/home/pnolan/idw/hello.cpp:8: undefined

reference to `ostream::operator<<(char const*)'

/tmp/ccInuSdg.o(.text+0x2f):/home/pnolan/idw/hello.cpp:8: undefined

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> Any pointers to where I should be looking for these library files most
> appreciated...:-)

Install your g++ development environment.

> #include <iostream>

> int main()
> {
> cout << "Hello, world!" << endl;
> return 0;
> }

% g++ -o hello hello.cc
%

% ./hello
Hello, world!
%

g++ -v -o hello hello.cc
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
/usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.cc /tmp/ccV3Vlpx.ii
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)

#include "..." search starts here:
#include <...> search starts here:

/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.4/include

/usr/include
End of search list.

The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
End of omitted list.
/usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccV3Vlpx.ii -quiet -dumpbase hello.cc -version -o /tmp/ccC9QoTW.s
GNU C++ version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease).
as -V -Qy -o /tmp/ccThoF6r.o /tmp/ccC9QoTW.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
/usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o -L/usr/lib/gcc-lib/i386-linux/2.95.4 /tmp/ccThoF6r.o -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o
%

Peter

[Paul Pluzhnikov]

"Peter Nolan" <pe...@peternolan.com> writes:

> A few prospects asked and I refused to try it out on linux because
> companies who don't want to pay for a zillions lines of OS software are
> not likely to pay for my software.....

That is a misconception: you are assuming that your customers run
Linux because they are cheapskates, but there are *plenty* of other
reasons to do so.

As this recent thread indicates:
http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/9a820f6a8f679da7
there are plenty of companies that spend significant $$ on commercial Linux software.

[Paul Pluzhnikov]

"Peter Nolan" <pe...@peternolan.com> writes:

> The command I am using to compile is as follows.
>
> g++ -o CDWU001 -DODBCVER=0x0352 -Dunix -Dlinux -g
> -I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
> CDWU001.cpp -L/usr/local/easysoft/unixODBC/lib
> -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread
> -lstdc++-3-libc6.2-2-2.10.0 -lstdc++ -lc -lm

Don't do *that*. Adding -lstdc++* and -lc to the command line
is *always* wrong (the compiler driver will do that for you).

Begin by performing a "sanity check":

$ cat junk.cc
#include <iostream>

int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}

$ g++ junk.cc && ./a.out
Hello, world!

If this produces any errors, your sanity check failed: your
installation of 'g++' is screwed up in some way, and you need to
work with sysadmins to restore sanity.

If this works, your system *is* sane; and your screwy command line
is the culprit. Here is what it probably should look like:

g++ -o CDWU001 -DODBCVER=0x0352 -g -pthread -I/home/pnolan/idw/include \
CDWU001.cpp -L/usr/local/easysoft/unixODBC/lib -lodbc

[Peter Nolan]

Hi Paul,
I have been in IT for 23 years and am well practiced at getting
compilers etc to work on all manner of systems....... ;-)..Just not
this particular compiler on this particular Linux.

I had already tried std::cout etc and it stubbornly refuses to find
them in the link. The code and the compile is below...I included the
-lstdc++ as an attempt to force these things to get loaded. I have
tried with and without pretty much every parameter and still get the
same results...I can assure you I have done all the normal sanity check
things. But with no luck. (I do my best not to use newsgroups to answer
obvious questions and I publish lots and lots of my source code as my
little contribution back for people being so kind as to assist me.)

It occurs to me that the most likely problem is that the library
containing these things is not installed or not being linked properly.
I have tried all manner of things to link them properly. A few appends
point out that in a back version the stdc++ lib got put in the wrong
place and had to be copied so I have tried to solve that as best I can
with only a regular users userid.

My most basic problem here is this. Unfortunately, the sysadmins do not
know how to compile code on linux as they don't do this here. So our
problem is how do we figure out how to get a compiler to work when the
sysadmins have no experience in this area. (and we are on opposite
sides of the planet so we only have a small window where we are both at
work.)

All suggestions on where I might look to see if the compiler install
has a problem or where I might find the link edit input files for
ostream etc would be most appreciated....:-)

Best Regards

Peter

#include <iostream>
using namespace std ;

int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;

}

g++ -o hello -DODBCVER=0x0352 -Dunix -g -I/home/pnolan/idw/include
-I/usr/include -I/usr/include/g++-3 hello.cpp
-L/usr/local/easysoft/unixODBC/lib

-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread -lc -lm -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cc1plus -v
-I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
-D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2
-D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux
-D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__
-DODBCVER=0x0352 -Dunix hello.cpp -D__GNUG__=3 -D__DEPRECATED
-D__EXCEPTIONS -quiet -dumpbase hello.cpp -g -version -o

/tmp/ccN0FZsC.s

GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
(i386-redhat-linux)
compiled by GNU C version 3.2.2 20030222 (Red Hat Linux
3.2.2-5).
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory

#include "..." search starts here:
#include <...> search starts here:

/home/pnolan/idw/include
/usr/include/g++-3
/usr/include/c++/3.2.2
/usr/include/c++/3.2.2/i386-redhat-linux
/usr/include/c++/3.2.2/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include

/usr/include
End of search list.

hello.cpp: In function `int main()':
hello.cpp:13: `cout' undeclared in namespace `std'
hello.cpp:13: `endl' undeclared in namespace `std'
[pnolan@nodsdvdb2 idw]$

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> I had already tried std::cout etc and it stubbornly refuses to find

Don't - your code is (more or less) fine. Don't give any options to
your compiler either - it doesn't need any.

> -lstdc++ as an attempt to force these things to get loaded. I have

There is no need to force it - that is what g++ links to by default.

> It occurs to me that the most likely problem is that the library
> containing these things is not installed or not being linked properly.

There is no need to think about it. Either you installed the g++
development libraries or you didn't!

> problem is how do we figure out how to get a compiler to work when the

You don't - it "just works".

> All suggestions on where I might look to see if the compiler install
> has a problem

Just check it against the package manifest.

> or where I might find the link edit input files for
> ostream etc would be most appreciated....:-)

Those are standard in the standard headers and standard libs.

> #include <iostream>
> using namespace std ;

> int main()
> {
> std::cout << "Hello, world!" << std::endl;
> return 0;
> }

> g++ -o hello -DODBCVER=0x0352 -Dunix -g -I/home/pnolan/idw/include
> -I/usr/include -I/usr/include/g++-3 hello.cpp

This is misguided for a start. Just compile with "g++ -o hello
hello.cc". If your compiler is set up wrong you will see it - adding
wrong stuff in here just invalidates the test.

> -L/usr/local/easysoft/unixODBC/lib
> -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -lodbc -lpthread -lc -lm -v

Remove all that stuff.

> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cc1plus -v
> -I/home/pnolan/idw/include -I/usr/include -I/usr/include/g++-3
> -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2
> -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux
> -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux
> -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE
> -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__
> -DODBCVER=0x0352 -Dunix hello.cpp -D__GNUG__=3 -D__DEPRECATED
> -D__EXCEPTIONS -quiet -dumpbase hello.cpp -g -version -o
> /tmp/ccN0FZsC.s
> GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386
> Linux/ELF)
> GNU C++ version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
> (i386-redhat-linux)
> compiled by GNU C version 3.2.2 20030222 (Red Hat Linux
> 3.2.2-5).
> ignoring nonexistent directory "/usr/i386-redhat-linux/include"

Missing headers? One might wonder.

> ignoring duplicate directory "/usr/include"
> as it is a non-system directory that duplicates a system directory
> #include "..." search starts here:
> #include <...> search starts here:
> /home/pnolan/idw/include
> /usr/include/g++-3
> /usr/include/c++/3.2.2
> /usr/include/c++/3.2.2/i386-redhat-linux

Are they populated?

> /usr/include/c++/3.2.2/backward
> /usr/local/include
> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include
> /usr/include
> End of search list.
> hello.cpp: In function `int main()':
> hello.cpp:13: `cout' undeclared in namespace `std'

This is a COMPILE problem. There is therefore absolutely no point in
your playing or worrying about librearies! Please do not confuse the
issue. Your headers are missing. Install them.

Do an expand with g++ -E and check the result.

Check your header install.

> hello.cpp:13: `endl' undeclared in namespace `std'
> [pnolan@nodsdvdb2 idw]$

Peter

[Peter Nolan]

Hi Peter,
I understand what you are saying....I added the variety of header
libraries to the compile and the code compiles....

I added the last append to show Paul quite clearly that adding std:: in
front of cout etc does nothing to help me. So, no, I am not confused
as to what the problem is...

I can get code to compile but I cannot get it to link because ostream
etc seem to be missing and I have scoured the machine and just can't
find them. As I stated, my problem is the admins for the machine do
not know how to compile a program and so they cannot help much. Unless
I can tell them what package is missing that they need to install on
that machine they say they cannot help me. We are looking around the
company for anyone who has compiled a program on linux/gnu but to date
we have found no-one. (???)

I know you say the compiler should just work, and I would like this to
be the case, and I have solved many compiler problems on many machines,
in many programming languages on many operating systems, but in this
case I have no linux experience and linux is not unix so my unix
experience is not translating effectively. And I am a mere regular
userid on this machine.

What I am trying to find out is, are the symptoms I am facing an
indication that there is a problem with the compiler install? If so,
how might I definitively find some log that proves it is a
compiler/linker problem? And if so how can I find out what package to
install onto the machine so I can ask the admins to install it?

I'm sure you can see my position. I have some software that will reduce
the time/effort to perform a piece of work for my client. The client
has chosen linux as their development environment yet they do not know
how to compile C++ software on their chosen platform. So I am simply
doing my best to fill the 'knowledge gap' of how to compile and link a
C++ program at the client starting with hello world.

This is the assistance I am seeking. I have tried for nearly 3 hours to
compile hello world with great varyation in all the compile/link
options and it simply does not compile, or if it compiles it does not
link.

I would really, really, really, appreciate a command that will compile
and link hello world on g++ 3.2.2 and linux.... :-)

Best Regards

Peter Nolan

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> I can get code to compile but I cannot get it to link because ostream

Don't worry about that! Compile it. We'll handle linkage later.

Now run ldd on the a.out (if one is produced). Also show me the link
stage of the g++ -v -o hello output.

Peter

[Peter Nolan]

Hi All,
This append is the simplest version of the program and show the results
with the command that produced the results.

Many people have suggested I put std:: in front of cout and endl but
when I do it says that these things are not defined in namespace
standard.

As I have said. I believe it is a compiler or linker (or both) install
problem. The admins have no experience at making a compiler work so I
expect they have little experience at installing compilers etc as well.

If it is not a compiler problem, if it is just me being a complete
novice on linux, I would LOVE a command that can compile and link this
program. I am happy to provide any input required for anyone to be able
to figure out what that command might be for this machine.

#include <iostream>
using namespace std ;

int main()
{
cout << "Hello, world!" << endl;
return 0;

}

g++ -o hello -g -I/usr/include -I/usr/include/g++-3 hello.cpp
-lc -lm -v -E

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cpp0 -lang-c++ -D__GNUG__=3
-D__DEPRECATED -D__EXCEPTIONS -v -I/usr/include -I/usr/include/g++-3

-D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2
-D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux
-D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__

hello.cpp -o hello

GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386
Linux/ELF)

ignoring nonexistent directory "/usr/i386-redhat-linux/include"

ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:

/usr/include/g++-3
/usr/include/c++/3.2.2
/usr/include/c++/3.2.2/i386-redhat-linux

/usr/include/c++/3.2.2/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include
/usr/include
End of search list.

g++: -lc: linker input file unused because linking not done
g++: -lm: linker input file unused because linking not done
[pnolan@nodsdvdb2 idw]$

g++ -o hello -g -I/usr/include -I/usr/include/g++-3 hello.cpp
-lc -lm -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cc1plus -v -I/usr/include

-I/usr/include/g++-3 -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__
-D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__
-D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386

-D__i386 -D__i386__ -D__tune_i386__ hello.cpp -D__GNUG__=3

-D__DEPRECATED -D__EXCEPTIONS -quiet -dumpbase hello.cpp -g -version -o

/tmp/ccr6aTRa.s

GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386
Linux/ELF)
GNU C++ version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
(i386-redhat-linux)
compiled by GNU C version 3.2.2 20030222 (Red Hat Linux
3.2.2-5).
ignoring nonexistent directory "/usr/i386-redhat-linux/include"

ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:

/usr/include/g++-3
/usr/include/c++/3.2.2
/usr/include/c++/3.2.2/i386-redhat-linux

/usr/include/c++/3.2.2/backward
/usr/local/include
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include
/usr/include
End of search list.

as -V -Qy -o /tmp/ccMseDSf.o /tmp/ccr6aTRa.s

GNU assembler version 2.14.90.0.4 (i386-redhat-linux) using BFD version
2.14.90.0.4 20030523

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/collect2 --eh-frame-hdr -m

elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtbegin.o
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../.. /tmp/ccMseDSf.o

-lstdc++ -lm -lc -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtend.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crtn.o

/tmp/ccMseDSf.o(.text+0x14): In function `main':
/home/pnolan/idw/hello.cpp:17: undefined reference to `endl(ostream&)'
/tmp/ccMseDSf.o(.text+0x21):/home/pnolan/idw/hello.cpp:17: undefined
reference to `cout'
/tmp/ccMseDSf.o(.text+0x26):/home/pnolan/idw/hello.cpp:17: undefined

reference to `ostream::operator<<(char const*)'

/tmp/ccMseDSf.o(.text+0x2f):/home/pnolan/idw/hello.cpp:17: undefined

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> has chosen linux as their development environment yet they do not know
> how to compile C++ software on their chosen platform.

They don't. You supply a Makefile and they type "make".

> I would really, really, really, appreciate a command that will compile
> and link hello world on g++ 3.2.2 and linux.... :-)

It's "g++ -o hello hello.cc", as countless people have SHOWN you. If
that doesn't work, their g++ development environment is not installed or
not installed correctly.

Note: g++ *development environment*.

Since you can compile it, it now behoves yu to show us the link stage
and what goes wrong, if anything.

Peter

[Peter Nolan]

Hi All,
success!!!

So,
for the next poor soul who comes along....the command that works is
just.

g++ -o hello -g -I/usr/include hello.cpp -lc -lm -v

Also just g++ -o hello hello.cpp works....

As I was testing I never took out -I/usr/include/g++-3 thinking it
could cause no problem...

I have no idea why allowing the search of another include library could
cause the problems we are seeing. It certainly looks like a g++ version
3 include library. But heck, the compile works and that's what I
wanted....

My thanks and appreciation to all those who replied both here and
directly to my email.

My apolgies for spending time on what has turned out to be the simple
matter of removing a reference to an include library.

Have a great weekend....for those of you who celebrate it...Happy
Thanksgiving.

[Peter T. Breuer]

Peter Nolan <pe...@peternolan.com> wrote:
> Hi All,
> success!!!

> So,
> for the next poor soul who comes along....the command that works is
> just.

> g++ -o hello -g -I/usr/include hello.cpp -lc -lm -v

/usr/include is part of the standard search path, so don't include it.
I can't see why you would ever need to link explicitly against libc and
libm either, since they ALSO are in the standard link set.

> Also just g++ -o hello hello.cpp works....

As if that were a surprise! Everyone has been telling you to remove
your options and just run "g++ -o hello hello.cc".

> As I was testing I never took out -I/usr/include/g++-3 thinking it
> could cause no problem...

> I have no idea why allowing the search of another include library could
> cause the problems we are seeing.

Because it comes at the wrong place and diverts the includes into
inappropriate dirs.

Peter

[Paul Pluzhnikov]

"Peter Nolan" <pe...@peternolan.com> writes:

> I have been in IT for 23 years and am well practiced at getting
> compilers etc to work on all manner of systems....... ;-)

Unfortunately, in those 23 years you appear to have failed to
understand the concept of sanity check :-(

What you are doing is screwing around with incorrect compile and
link lines, and then failing to understand that incorrect compile
and link lines you yourself produced cause you the grief.

Either do *exactly* what you are told:

g++ hello.cpp

or you'll not get much further help (at least not from me).

> g++ -o hello -DODBCVER=0x0352 -Dunix -g -I/home/pnolan/idw/include
> -I/usr/include -I/usr/include/g++-3 hello.cpp

^^^^^^^^^^^^^^^^^^^^
This is probably the root
cause of all your problems.

[Peter Nolan]

Paul,
interesting enough, the last time I was using gnu c++ the guy who was
the compiler expert told me to put a similar library to
-I/usr/include/g++-3 into the compile options and told me it was
required, and sure enough without it the code did not compile.

So, yes, this extra parameter was the cause of the grief in this case.
Mea Culpa...

Best Regards
Peter
www.peternolan.com