Build error with gsoap

Ouch... You're making this way harder than required.

To use gsoap, do this.

1) Install Ubuntu Bionic as your OS.

2) apt-get install libgsoap libgsoap-dev

You will have gsoap-2.8.60 installed + working 100% in a few seconds.

If you think you must build from source

1) Start with more recent version of gsoap.

2) Use recent gcc (so v7 or v8).

3) If problems arise, like you mention above, this points to something in the gsoap build from source instructions being incomplete or incorrect, so you'll open a ticket with gsoap development to tell you correct steps + also fix their documentation.

Or... more likely... based on the error you reported, you're attempting to build gsoap in some ad-hoc (hand rolled) way rather than following gsoap build directions... exactly...

First step... if you must build from source... remove everything + start over again, following build instructions exactly.

This is incorrect I'm afraid.

As you will see from my original E-mail I am doing everything correctly when I'm building gSoap.

All works ok on IBM AIX.

But, on Linux gcc and g++ are causing conflicting issues.  I raised with Genivia and Robert said :  

                   Mixing C and C++ source code files may cause linkage issues, so rename .c files to .cpp files to avoid that.

                   There is extensive use of 'extern "C"' that should prevent linkage issues, which works fine with most compilers, but there is always an exception to the rule...

Any other ideas please ?

Thanks.

1) This is the first mention of AIX... I sometime wake up in the dark... with nightmares... I'm still working with AIX... shudder...

Best option is to use XLC or whatever IBM calls their internal compiler today.

Or if they now default to using gcc, then use gcc + be sure to use the AIX loader, rather than the gcc loader.

Most AIX build problems arise during link phase.

2) You said, "Mixing C and C++ source code files may cause linkage issues, so rename .c files to .cpp files to avoid that."

This is correct. Use .cpp for all files, so only C++ is in the mix.

3) Since you're building from source, use latest gsoap source which shows to be gsoap-2.8.75 which will contain any gsoap build system updates.

4) Then, post your entire build process... All commands you're using to build gsoap, which will either be a make or cmake command set.

Also if libtool is in the mix, run libtool to show it's version.

Tip: Long ago, when I worked on contract at IBM, I build a massive amount of open source software to get my job done.

The approach I took was this.

1) Bootstrap the gcc toolchain using XLC.

2) Bootstrap additional toolchain components including - m4 + autoconf + automake + libtool - using gcc.

3) Then use gcc for source compilation.

4) The use XLC for linkage step.

This worked fairly well, as I could build the entire LAMP Stack along with other complex software, like ffmpeg, correctly every time.

I don't think we understand one another...

The code builds, compiles and links on IBM AIX - no problems.

I have a task of importing the code to Linux where gcc and g++ compiler are used.

I cannot rename all the files from .c to .cpp because the .c files are auto generated from .tc (and if I rename .tc to .tcpp the converter will not know what .tcpp is).

Any ideas please ?

I should also say that the build process for gSoap is easy...

All I'm doing is configure and then make and I get the libraries.

But is it possible that the linker does not see the function "soap_faultcode" because I should use -DWITH_NONAMESPACES ?

I did this but it did not matter.

Please can I have honest answer if you can help because as it stands I'll cancel my membership very soon !

Here's the problem.

Hardly anyone has access to AIX machines.

If you can provide ssh access to your machine + all commands in your exact build, then runtime sequence.

Likely someone could figure out how to answer your question.

I cannot do that I'm sorry - it's the machine in the company.

The AIX build is not a problem.

As I keep saying, when I take the code and try on Linux (i.e. using gcc and g++), I'm getting the linking errors.

It seems that the linker cannot find the definition and implementation for "soap_faultcode".  The linker can only see the call to this function.

So how do I make the linker find the he definition and implementation for "soap_faultcode" ?  It's a static library I'm linking too.

Oh...

If you're saying you're building binaries on AIX + attempting to move these to a non-AIX system, this has no prayer of ever working.

Because AIX binaries are a completely different format than Linux... unless you're somehow forcing the XLC loader/linker to build ELF binaries... which might be possible these days. No way to do this, when I last worked on AIX.

If this is really what you're trying to do, it's very wrong. Instead build gsoap (same source versions) on AIX + then do another build on your Linux Distro.

On Linux you can debug library problems easily, using ldd, as in this example...

# ldd $(which apache2)
	linux-vdso.so.1 =>  (0x00007fffc097a000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6decf3d000)
	libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007f6decd12000)
	libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f6decadd000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6dec8bf000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6dec4f8000)
	libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f6dec2be000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f6dec094000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6debe8f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6debc8b000)
	/lib64/ld-linux-x86-64.so.2 (0x000055ec071b3000)

Select allOpen in new window

In your case, you'll point ldd at some either library or executable program, which will show the missing libraries.

You'll then require making those libraries available + doing whatever ldconfig magic is required so all executables can find your non-standard built libraries.

Caution: If you've installed a version of gsoap using your Linux Distro's package manager, then install a hand rolled (source build) version, then attempt to make your hand rolled versions globally available using ldconfig...

You must have some serious command line Kung Fu.

If you make a mistake, you'll likely end up with gsoap dependent executables installed by the Distro's package manager crashing with super odd errors.

Tip: If you have a missing extern, there are 2x possibilities.

1) You're actually building + linking to shared objects. This is unlikely, if you did a static build.

2) You're trying to move AIX code to a Linux machine + the Linux machine is losing it mind. This is likely, based on what you mentioned in your last update.

Of course that I'm not doing that !

I meant that I'm taking code that builds perfectly on AIX on to Linux and trying to build it there.

Part of this code is gSoap but once again the libraries are build from scratch on each platform (but on Linux I'm getting linking errors).

Any ideas ?

Next step is to provide all steps you type on the command to do your build.

Both on AIX + Linux.

Likely something will stand out.

To build gSoap I'm just getting the zip file from their web site, run :-


./configure

./make

and I then end up with 6 libraries :-  find . -name '*soap*.a' -print

I then : cd gSoap-2.8/gSoap

and then : nm *soap*.a | grep faultcode

I'm getting : U soap_faultcode (U stands for Undefined)

Could you please try this on your Linux machine ?  Please download gSoap version 2.8.36

If you're getting the same, then it tell me that I'm not doing anything wrong but there is a bug with this version of gSoap.

Please then try the same steps with a more recent version (such as 2.8.74) and tell me what you're getting.  I believe we want to be in a situation where 'nm' finds the function soap_faultcode

Thanks.

I would actually look how (and where) soap_faultcode is defined.
And then, as Imanuel says, nm is your friend.

Thanks.

But that's the problem - I know that soap_faultcode is defined in the soapcpp2-generated soapC.cpp file.

But Mixing C and C++ causes linkage issues.

So what do I do ?

Could you try downloading gSoap version 2.8.36 and build on Linux and see if you can build a small application with C and C++ (without using extern "C") and see if this resolves using a later version of gSoap.

Thanks.

Unfortunately, I don't have a linux environment for the moment.

If you link C to C++ there is no problem, you can't link C++ to C because of the name mangling. You have to define a C interface to the C++ calls.

Why do you look only at the .a files? The error above comes from a .so (dynamic library).

No ,it does not :-

....
libgsoapssl.a(libgsoapssl_a-stdsoap2_ssl.o): In function `soap_set_fault':
stdsoap2_ssl.c: (.text+0x2b1e1 ): undefined reference to `soap_faultcode'
stdsoap2_ssl.c: (.text+0x2b1f1 ): undefined reference to `soap_faultstring'
stdsoap2_ssl.c: (.text+0x2b88b ): undefined reference to `soap_faultsubcode'
stdsoap2_ssl.c: (.text+0x2b8dd ): undefined reference to `soap_faultsubcode'
....

The problem I have : I am trying to establish whether it a problem with the gSoap version or platform.  All is working ok on AIX.  But on Linux, I'm getting the errors.

Currently, I'm in no position to download more recent version of gSoap, so asked for your help.

Does anyone there have Linux ?

You guys are supposed to be experts...

Alternatively, can you send an E-mail to Genivia and ask them about this ?  I received a message from them saying that since I don't have access to the gSoap code (to define the interface you are referring to), I would need to rename all my .c files to .cpp but I'm not in any position to do that (there are more than 10,000 files with more than 10m lines of code).

I then asked Genivia if this was fixed in a later version but no reply.

Could you try ?

Sorry, I don't have access to a linux environment right now. I'll have a look at it in about 8 hours, if you don't find a solution by then.

Thank you.

I have not managed to find a solution for a week now, so any help appreciated...

Hello

Any other ideas please ?

I have to be honest, I am quite disappointed with the advice given so far...

Unless I'm given some practical reasonable solutions, I will be looking to cancel my membership by the end of the week !

Thanks

Imanuel.