Modify

Ticket #6147 (closed Bugs: fixed)

Opened 4 years ago

Last modified 11 months ago

message_queue sample fails to compile in 32-bit

Reported by: Graham Perks <graham@…> Owned by: igaztanaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.56.0 Severity: Regression
Keywords: Cc: darthpjb@…

Description

Just upgraded to 1.48.

On OS X I compile the sample program with: gcc -I <blah path to boost>/include -arch i386 main.cpp

and it fails with "....boost/interprocess/ipc/message_queue.hpp:330: error: no matching function for call to ‘get_rounded_size(long unsigned int, const unsigned int&)’"

It's the MQ creation line that fails. If I build for x64, it compiles successfully. The source is:

#define BOOST_DATE_TIME_NO_LIB #include <boost/interprocess/ipc/message_queue.hpp> #include <iostream> #include <vector>

using namespace boost::interprocess;

int main () {

try{

Erase previous message queue message_queue::remove("message_queue");

Create a message_queue. message_queue mq (create_only only create

,"message_queue" name ,100 max message number ,sizeof(int) max message size );

Send 100 numbers for(int i = 0; i < 100; ++i){

mq.send(&i, sizeof(i), 0);

}

} catch(interprocess_exception &ex){

std::cout << ex.what() << std::endl; return 1;

}

return 0;

}

Attachments

Change History

comment:1 Changed 4 years ago by Graham Perks <graham@…>

Retry code formatting. It's the sample from the boost docs.

#define BOOST_DATE_TIME_NO_LIB
#include <boost/interprocess/ipc/message_queue.hpp>
#include <iostream>
#include <vector>

using namespace boost::interprocess;

int main ()
{
    try{
        //Erase previous message queue
        message_queue::remove("message_queue");
        
        //Create a message_queue.
        message_queue mq
        (create_only               //only create
         ,"message_queue"           //name
         ,100                       //max message number
         ,sizeof(int)               //max message size
         );
        
        //Send 100 numbers
        for(int i = 0; i < 100; ++i){
            mq.send(&i, sizeof(i), 0);
        }
    }
    catch(interprocess_exception &ex){
        std::cout << ex.what() << std::endl;
        return 1;
    }
    
    return 0;
}

comment:2 Changed 4 years ago by Graham Perks <graham@…>

If anyone has a workaround for this, it would be much appreciated.

comment:3 Changed 4 years ago by Graham Perks <graham@…>

I was able to workaround this by adding this code before including the boost headers. It adds a second type to the get_rounded_size template.

namespace boost {
    namespace interprocess { 
        namespace ipcdetail {
            
            //Rounds "orig_size" by excess to round_to bytes
            template<class SizeType, class ST2>
            inline SizeType get_rounded_size(SizeType orig_size, ST2 round_to)
            {
                return ((orig_size-1)/round_to+1)*round_to;
            }
        }
    }
}

comment:4 Changed 4 years ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in trunk and release branches adding

#include <boost/interprocess/detail/utilities.hpp>

to message queue header.

comment:5 Changed 3 years ago by moala@…

  • Status changed from closed to reopened
  • Version changed from Boost 1.48.0 to Boost 1.50.0
  • Resolution fixed deleted

Still not fixed in i386 GCC 4.2 xcode 3.2.6 (only works in x86_64) even with this

#include <boost/interprocess/detail/utilities.hpp>

inclusion in message_queue.hpp in boost 1.50 (macports) (with Mac OS X 10.6 SDK / deployment target 10.5).

Graham Perks's workaround allows compiling.

comment:6 Changed 3 years ago by igaztanaga

I successfully compiled your test using trunk code in Mac OS 10.6.2 with GCC:

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)

can you check the bug is fixed?

comment:7 Changed 23 months ago by igaztanaga

  • Status changed from reopened to closed
  • Resolution set to worksforme

No news from the reporter so I'm closing the issue.

comment:8 Changed 13 months ago by darthpjb@…

  • Status changed from closed to reopened
  • Resolution worksforme deleted

I can confirm that this issue is still relevant (as mentioned by moala) in boost 1_56_0.

32bit Intel builds for 10.7.5 fail as above on LLVM GCC 4.2 - The mentioned workaround did indeed solve the problem for me also.

Note that I am static-linking boost, and forcing the compiler to GNU99 dialect. These may be related?

If needed I may be able to create a reproducing project.

comment:9 Changed 12 months ago by darthpjb@…

I can now further confirm the issue is also apparent on I386 builds using LLVM GCC 5.1, for the 10.9 SDK, Xcode 5.1.1.

It would seem this does actively apply to the most recent LLVM compilers, across the full range of Mac OSX builds. As long as the target architecture is 32bit.

comment:10 Changed 12 months ago by darthpjb@…

Further Confirmation: The issue is also present on OSX 10.5.8, Xcode 3.1.4, Using Apple GCC 4.0

Graham Perk's fix does, once again, solve the issue.

comment:11 Changed 12 months ago by anonymous

  • Version changed from Boost 1.50.0 to Boost 1.56.0

comment:12 Changed 12 months ago by darthpjb@…

  • Cc darthpjb@… added

comment:13 Changed 12 months ago by igaztanaga

Without access to the platform, I can't know where the problem lies. However, one alternative could be specifying the template type in get_rounded_size. That is:

replace "get_rounded_size(a, b)" calls with "get_rounded_size<size_type>(a, b)".

Please let me know if this fixes the problem

Last edited 12 months ago by igaztanaga (previous) (diff)

comment:14 Changed 11 months ago by bbaldino@…

For what it's worth, I had this same problem on OSX (with boost 1.56) and this workaround got things compiling.

comment:15 Changed 11 months ago by igaztanaga

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed in Boost 1.57 Beta.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.