Hi Robert, As Bill mentioned, the ./configure options mentioned in the INSTALL file is for users who have downloaded the source distribution. You can use the same options by first running the autogen.sh which will generate the configure file and other necessary files by executing the GNU Autotools. After then , you can run ./configure --help command to see the options. Using the options you can configure with xml parser to use, which directory to use as the install directory ect.
In order to run the samples, you would need the AXIS2C_HOME environment variable set. run_tests.sh file assumes that the compiled binary package is a directory named 'deploy' in the source checkout. Regards Nandika On Mon, 3 Mar 2025 at 02:00, Bill Blough <de...@blough.us.invalid> wrote: > Hi Robert, > > On Sun, Mar 02, 2025 at 07:14:20AM -1000, robertlazarski wrote: > > > > The INSTALL doc is confusing as it says run ./configure as usual but it > > isn't there without executing the script. > > I think the INSTALL doc is typically for the end user, so it expects > building from a dist tarball, which would already have ./configure > generated. But for development purposes, it's my understanding that > it's best practice to not check ./configure (and other, generated build > system files) into the repo. So when starting from a checkout rather > than a dist tarball, it requires that autoconf, automake, etc. be run to > get to a buildable state. > > Maybe we should also have an INSTALL.developers (or whatever). > > > > > Running "sh build_for_tests.sh" shows errors in the Makefile: > > > > /usr/bin/install: 'AUTHORS' and > > '/home/robert/repos/axis-axis2-c-core/AUTHORS' are > > the same file > > make[2]: *** [Makefile:504: install-dataDATA] Error 1 > > make[2]: Leaving directory '/home/robert/repos/axis-axis2-c-core' > > make[1]: *** [Makefile:948: install-am] Error 2 > > make[1]: Leaving directory '/home/robert/repos/axis-axis2-c-core' > > make: *** [Makefile:636: install-recursive] Error 1 > > > > That's strange. For what it's worth, I can do a brand new checkout, > then run build_for_tests.sh, and it completes successfully with no > errors, installing a complete binary distribution (with samples) into > $src_dir/deploy. > > Since it looks like it's trying to install into the root of the source > tree instead of the deploy subdir, I'm guessing there's an issue with how > AXIS2C_HOME is getting set on your system, which is causing issues with > the install prefix. It should all be set up in build_for_tests.sh, so > you might start there. > > > In the end I manually edited the Makefile so "install" would complete - > as > > shown via diff, I need to find the right place to fix this: > > Since (as far as I can tell) the existing line should be correct, I > think once you figure out the AXIS2C_HOME and/or prefix/destdir issue > referenced above, then the diff, or any further/related fix, shouldn't > be necessary. > > I'm happy to try to help you work through it, but as I said, it "works > on my machine" so much of my help would probably answering questions or > making suggestions based on the info you give me. > > > > > Running "sh run-tests.sh" shows one error - an HTTP 500 error on "Service > > not Found" which arguably could be a 404. The log dir shows: > > > > [Sun Mar 2 06:03:09 2025] [info] Service Not found. Endpoint reference > is > > : http > > ://127.0.0.1:9090/axis2/services/echo/echo > > <snip> > > > > > Then it fails here - about : > > > > AddressSanitizer: CHECK failed: sanitizer_thread_arg_retval.cpp:57 > > "((!t->second.deta > > ched)) != (0)" (0x0, 0x0) (tid=335462) > > I suspect this is related to install issue above. The installed > file isn't where the test server is expecting it, so when it tries to > load it, there's a null pointer dereferece. (There are a lot of > functions and code paths that lack null pointer checks - which is > something I wanted to improve at some point) > > If I do run_tests.sh, then all tests pass. However, I can duplicate > what you're seeing by renaming deploy/services/echo to something else. > So I think sorting out the install function will fix this, too. > > > > > > > ./configure --enable-json > > > > Returns this error. Seems like you applied the patch to support JSON back > > in 2013. > > > > https://issues.apache.org/jira/browse/AXIS2C-1645 > > > > Is there some Ubuntu package I need to install? Simply "json" not found > > isn't clear to me. I see json.h in a couple places. I tried "apt > > install libjson-c-dev" > > from Ubuntu 22.04 since it also has json_object but it didn't help. > > > > checking for json... no > > configure: error: Package requirements (json) were not met: > > > > Package 'json', required by 'virtual:world', not found > > According to this comment > https://issues.apache.org/jira/browse/AXIS2C-1645?focusedCommentId=13758315&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13758315 > it sounds like libjson-c-dev is the correct package, but it looks like > the references to library references to "json" still need to be replaced > with > "json-c". > > In doing that, I got configure to succeed, but then got compiler errors. > It looks like json-c needs C99 or newer. So I added --std=c99 when JSON is > enabled, and was able to get a clean compile. I haven't done any > testing. (side note: maybe we should make the whole project require c99 > for the 2.0 release, not just when JSON is enabled). > > I've attached the patch with my changes. > > Best regards, > Bill > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org > For additional commands, e-mail: c-user-h...@axis.apache.org
