[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | C++ |
| Notice: | Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS) |
| Moderator: | DECCXX::AMARTIN |
|
| Created: | Fri Nov 06 1987 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3604 |
| Total number of notes: | 18242 |
3535.0. ".cxx extension and posix calls" by ZYDECO::REDDY () Thu Apr 10 1997 20:06
I am running Cxx version 5.5 on Digital UNIX 4.0b. When I compile the following
program, I get unresolved symbols:
% cxx mark.cxx -lrt
ld:
Unresolved:
mq_open(const char*, int, ...)
mq_send(int, const char*, unsigned long, unsigned int)
The same program will compile correctly if I change the name of the
program to mark.c
% cxx mark.c -lrt
Why does it not work with the .cxx extension? Am I missing something?
Thanks,
Sumithra
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <time.h>
#include <sched.h>
#include <sys/mman.h>
#include <sys/fcntl.h>
#include <signal.h>
#include <sys/rt_syscall.h>
#include <mqueue.h>
#include <errno.h>
#define PMODE 0666
extern int errno;
int main()
{
int i;
int status = 0;
mqd_t mqfd;
char msg_buffer[792];
struct mq_attr attr;
int open_flags = 0;
int num_bytes_to_send;
int priority_of_msg;
printf("START OF TEST_SEND \n");
/* Fill in attributes for message queue */
attr.mq_maxmsg = 1024;
/* attr.mq_msgsize = P4IPC_MSGSIZE; */
attr.mq_msgsize = 1024;
attr.mq_flags = 0;
/* Set the flags for the open of the queue.
* Make it a blocking open on the queue, meaning it will block if
* this process tries to send to the queue and the queue is full.
* (Absence of O_NONBLOCK flag implies that the open is blocking)
*
* Specify O_CREAT so that the file will get created if it does not
* already exist.
*
* Specify O_WRONLY since we are only planning to write to the queue,
* although we could specify O_RDWR also.
*/
open_flags = O_WRONLY|O_CREAT;
/* Open the queue, and create it if the receiving process hasn't
* already created it.
*/
mqfd = mq_open("myipc",open_flags,PMODE,&attr);
if (mqfd == -1)
{
perror("mq_open failure from main");
exit(0);
};
/* Fill in a test message buffer to send */
memset(msg_buffer,'a',792);
num_bytes_to_send = 792;
priority_of_msg = 1;
/* Perform the send 10 times */
i = 0;
while ( 1 ) {
status = mq_send(mqfd,msg_buffer,num_bytes_to_send,priority_of_msg);
if (status == -1)
perror("mq_send failure on mqfd");
else
printf("successful call to mq_send, i = %d\n",++i);
}
/* Done with queue, so close it */
if (mq_close(mqfd) == -1)
perror("mq_close failure on mqfd");
printf("About to exit the sending process after closing the queue \n");
}
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3535.1 | The .cxx vs .c extension | DECC::SULLIVAN | Jeff Sullivan | Thu Apr 10 1997 21:25 | 19 |
| On Digital UNIX, the "cxx" command is actually a driver which invokes the
compiler and any other tools it needs to do the compilation or linking. When you
specify the .cxx extension, the driver invokes the DEC C++ compiler "gemc_cxx".
When you specify the .c extension, the driver invokes the DEC C (not C++)
compiler. So you are really comparing apples to oranges...
Use the -v switch to verify what the driver is doing in this case:
% cxx -v hello.cxx
/usr/lib/cmplrs/cxx/gemc_cxx ...
% cxx -v hello.c
/usr/lib/cmplrs/cxx/cc ...
The problem with the undefineds may be due to C++ name mangling (missing extern
"C" blocks), but I did not verify where they were missing from.
-Jeff
|
| 3535.2 | the extension determines how it's compiled... | DECC::J_WARD | | Thu Apr 10 1997 21:33 | 20 |
|
If you use a .c extension, cxx will assume it's a C source file
and compile it that way. If you use .cxx then cxx will it's C++.
The problem seems to be that the prototypes for the functions
are not declared extern "C" inside mqueue.h.
You can fix this by surrounding your include, i.e.:
#if defined(__cplusplus)
extern "C" {
#endif
#include <mqueue.h>
#if defined(__cplusplus)
}
#endif
I think the maintainers of the mqueue.h header file
should fix this header to allow C++ users to
use this header without having to do the extern "C" themselves...
|
| 3535.3 | File an OSF_QAR | DECC::SULLIVAN | Jeff Sullivan | Thu Apr 10 1997 23:58 | 17 |
| Re: -.1
> I think the maintainers of the mqueue.h header file
> should fix this header to allow C++ users to
> use this header without having to do the extern "C" themselves...
I agree.
The way to get that done is to file an OSF_QAR. You can do that via the web at
http://webster.zk3.dec.com/webqar or by logging into node GORGE as
"QAR_INTERNAL". If you have trouble doing either of those things, let me know
and I'll file it for you.
Please post the QAR number here so that others with the same problem can look it
up using the number.
-Jeff
|
| 3535.4 | Thanks | ZYDECO::REDDY | | Fri Apr 11 1997 14:42 | 5 |
| Thank you for the answer. I will use the workaround suggested in .2.
If no one has filed a qar, I will file one on Monday and post the qar
number here.
|
| 3535.5 | OSF_QAR info | DECC::SULLIVAN | Jeff Sullivan | Fri Apr 11 1997 15:20 | 18 |
| > If no one has filed a qar, I will file one on Monday and post the qar
> number here.
No qar has been files yet, to my knowledge. Of course, if it's a duplicate, I'm
sure the maintainer will tell you so and close it accordingly. Some defect
tracking systems actually bump up the priority of the report, if duplicates were
reported. Obviously, the more reports, the more common the problem and hence the
more important it is to fix. I don't think this QAR system has that feature, but
the maintainer may take the hint.
The advantage to filing a qar yourself is that you will be mailed updates (in
theory anyway) when the qar status changes. If I filed a qar for you, that info
might not get back to you. If the status is important to you or a customer, it's
better to do-it-yourself.
If you have problems, let us know.
-Jeff
|