[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-1416481 ] Can't link against C++ application out of the box
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2006-01-27 20:45:25
Message-ID: E1F2aTF-0003RT-Tt () sc8-sf-web2 ! sourceforge ! net
[Download RAW message or body]

Bugs item #1416481, was opened at 2006-01-27 15:53
Message generated for change (Comment added) made by tanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1416481&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configure
Group: linux
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't link against C++ application out of the box

Initial Comment:
The present configure script creates Makefiles which
are unable to link against C++ applications. The main
application that the NetSNMP agent talks to must at
present be a C application. A small fix (see below)
allows the linking of C++ apps as well. (this is
assuming gcc and g++ are the compilers in use)

All you need to be able to link the agent in to a C++
application, is a small change to the Makefiles in the
agent and apps directories. When linking the Makefile
needs to give g++ as the first "argument" to libtool,
rather than gcc. Below is a patch file for fixing the
two Makefiles. Note the below patch isn't on the
netSNMP distribution, but on the Makefiles themselves,
but it should show you what the Makefiles need to look
like in order to support C++ applications.

The real fix for this needs the code/templates which
autogenerate the Makefiles to be changed, so that
./configure produces the patched version of the
Makefiles. Once that's done, netSNMP should work with
C++ out of the box.

Given the number of times that C++ has come up before
on this list, I hope this fix will be useful to folk =)

Cheers

Raffles

--- Makefile	2006-01-27 11:28:49.245467235 +0000
+++ Makefile.bis	2006-01-27 11:29:57.149984444 +0000
@@ -51,6 +51,7 @@
 
 # Misc Compiling Stuff
 CC	        = gcc
+LINKCC	        = g++
 
 # use libtool versioning the way they recommend.
 # The (slightly clarified) rules:
@@ -68,11 +69,11 @@
 LIBAGE      = 0
 LIBREVISION = 0
 
-LIB_LD_CMD      = $(LIBTOOL) --mode=link $(CC)
$(CFLAGS) -rpath $(libdir) -version-info
$(LIBCURRENT):$(LIBREVISION):$(LIBAGE) -o
+LIB_LD_CMD      = $(LIBTOOL) --mode=link $(LINKCC)
$(CFLAGS) -rpath $(libdir) -version-info
$(LIBCURRENT):$(LIBREVISION):$(LIBAGE) -o
 LIB_EXTENSION   = la
 LIB_VERSION     =
 LIB_LDCONFIG_CMD = $(LIBTOOL) --mode=finish $(libdir)
-LINK		= $(LIBTOOL) --mode=link $(CC)
+LINK		= $(LIBTOOL) --mode=link $(LINKCC)
 # RANLIB 	= ranlib
 RANLIB		= :
 


----------------------------------------------------------------------

>Comment By: Thomas Anders (tanders)
Date: 2006-01-27 21:45

Message:
Logged In: YES 
user_id=848638

I agree with Dave that "./configure --with-cc=g++" is the
suggested approach. If compilation fails with g++, then
*this* is what needs to be fixed. Can you come up with the
list of errors that g++ (which version and platform?)
complains about when compiling 5.3.0.1?

----------------------------------------------------------------------

Comment By: Raffles (finking)
Date: 2006-01-27 16:35

Message:
Logged In: YES 
user_id=1409123

Copied from the mailing list as it seemed useful:

Hi Dave,

./configure --with-cc=g++ compiles the entire agent with the
C++ compiler, which I definitely want to avoid - the
semantics are subtly different and it would be very easy to
introduce bugs without realising it. As it happens I kicked
it off just before I started this reply and the build failed
with a compilation error in mib.c "invalid conversion from
`const char*' to `const u_char*'"

My angle on the linking is that using g++ instead of gcc
just means that a few extra libraries are included as
standard. I think they both use ld under the bonnet don't
they (I could be wrong about this)? If the application code
is entirely C then presumably the C++ libraries just won't
get linked in - i.e. same effect as manually adding extra -l
flags which you don't need.

I can understand that you might not be happy with this as
standard though. If you look at the patch I've done, all it
requires is a separate variable for the name of the compiler
used during linking (I called it LINKCC). Could we not make
it standard in the Makefiles to use $(CC) for compiling and
$(LINKCC) for linking, so that you could do

./configure --with-linkcc=g++

The default setting could still be gcc that way, but of
course it would then be possible to put some helpful info in
the ./configure --help output, which should make it much
easier to use.

I hope this is useful.

Regards

Robert Finking

Dave Shield wrote:
> On Fri, 2006-01-27 at 14:39 +0000, Raffles wrote:
>  > OK I've fixed it. All you need to be able to link the
agent in to a C++
>  > application, is a small change to the Makefiles in the
agent and apps
>  > directories. When linking the Makefile needs to give
g++ as the first
>  > "argument" to libtool, rather than gcc.
> 
>  > The real fix for this needs the code which
autogenerates the Makefiles
>  > to be changed, so that ./configure produces the patched
version of the
>  > Makefiles.
> 
> I don't think we'd want to switch to linking with g++ as a
matter of
> course.  Net-SNMP is fundamentally a C-based project, not
a C++ one.
> It's up to the person wanting to use in a "non-standard"
way to make
> the necessary adjustments.
>    But it would certainly be useful if those adjustments
could be as
> simple as possible.
> 
> What happens if you run
> 
>         ./configure --with-cc=g++
> 
> ?
> 
> Dave
> 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1416481&group_id=12694


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic